Firefox exploit found in the wild • Hacker News Board

Re: Firefox exploit found in the wild

#31

Post by wereHamster » Fri, Aug 07, 2015, 10:03 AM UTC

jacquesm wrote: post #27

wereHamster wrote: post #21

Earlier quoted context omitted.

Run the browser in a container or in a sandboxed environment (kindof like chroot, but note that chroot itself should not be used for security purposes). There may be docker containers with just firefox, if not it's easy to create one. Or use vmware, though that is much more heavyweight than sandboxing or containers.

Docker would seem to me to be the wrong solution in this case.

Instead of

    $ firefox

you start

    $ docker run mozilla/firefox

and get instant process isolation and protection from these kinds of exploits.

Heck, mozilla could use the same underlying mechanisms internally (cgroups, namespaces) that docker already uses without introducing the dependency on docker (if that's whats bothering you). So while the implementation may not be ideal (installing docker is an overhead, I acknowledge that), what it does technology-wise is an improvement for security.

Re: Firefox exploit found in the wild

#32

Post by Nanzikambe » Fri, Aug 07, 2015, 10:03 AM UTC

The lack of additional detail in this very sparse announcement really compromises users' ability to damage control effectively.

Would like to know if an installation is vulnerable if:

    1) If Applications, PDF is set to "Always ask"
    2) Ublock and/or privoxy are used
    3) Javascript is disabled
    4) pdfjs.previousHandler.alwaysAskBeforeHandling == false
    5) pdfjs.disabled == true

Also which advertising network and which Russian site would be helpful for blocklists.

Re: Firefox exploit found in the wild

#33

Post by _pmf_ » Fri, Aug 07, 2015, 10:04 AM UTC

aembleton wrote: post #2

If at all possible it would be worth naming and shaming the advertising network that is allowing this exploit through. Why do advertising networks allow advertisers to exectue Javascript? What need is there for it? Every time one of these exploits that use advertising networks is found, it just increases the value of blockers such as uBlock. Whether you accept adverts or not, you shouldn't have to accept javascript b…

> Why do advertising networks allow advertisers to exectue Javascript?

Because there is an empty place in their wallet that they require to be filled.

Re: Firefox exploit found in the wild

#34

Post by st0p » Fri, Aug 07, 2015, 10:05 AM UTC

jacquesm wrote: post #19

Dosenpfand wrote: post #15

Earlier quoted context omitted.

> And what a pdf reader has to do with javascript is a mystery as well. The whole reader is written in Javascript: https://mozilla.github.io/pdf.js/

Oh great. What could possibly go wrong, give javascript access to local storage through some 'hard to trigger' gate. That's just asking for it. Hindsight and all that but still, this is not a good idea. A browser should not use it's own internal language sandboxed for the web to have access to the local system through some loophole. It's only a matter of time before such a loophole becomes an exploit. I wonder if jav…

WebRTC ;)

https://en.wikipedia.org/wiki/WebRTC

Re: Firefox exploit found in the wild

#35

Post by k8tte » Fri, Aug 07, 2015, 10:07 AM UTC

jacquesm wrote: post #19

Dosenpfand wrote: post #15

Earlier quoted context omitted.

> And what a pdf reader has to do with javascript is a mystery as well. The whole reader is written in Javascript: https://mozilla.github.io/pdf.js/

Oh great. What could possibly go wrong, give javascript access to local storage through some 'hard to trigger' gate. That's just asking for it. Hindsight and all that but still, this is not a good idea. A browser should not use it's own internal language sandboxed for the web to have access to the local system through some loophole. It's only a matter of time before such a loophole becomes an exploit. I wonder if jav…

Uh, welcome to the web @ 2015

Re: Firefox exploit found in the wild

#36

Post by joosters » Fri, Aug 07, 2015, 10:09 AM UTC

Firefox's 'About' page seems to lack enough information here.

My page just said 'Firefox 39 available' and 'restart to upgrade'. But the exploit page notes that you need version 39.0.3 in order to be protected. So it's unclear if the upgrade would fix things or not.

Re: Firefox exploit found in the wild

#37

Post by jacquesm » Fri, Aug 07, 2015, 10:09 AM UTC

wereHamster wrote: post #31

jacquesm wrote: post #27

Earlier quoted context omitted.

Docker would seem to me to be the wrong solution in this case.

Instead of $ firefox you start $ docker run mozilla/firefox and get instant process isolation and protection from these kinds of exploits. Heck, mozilla could use the same underlying mechanisms internally (cgroups, namespaces) that docker already uses without introducing the dependency on docker (if that's whats bothering you). So while the implementation may not be ideal (installing docker is an overhead, I acknowle…

It appears that since we're discussing this on a page related to a firefox issue of exactly that nature that this approach is insufficient.

Re: Firefox exploit found in the wild

#38

Post by rogeryu » Fri, Aug 07, 2015, 10:11 AM UTC

jacquesm wrote: post #3

I don't even want my browser to have a 'local file context', is there a way to switch such behavior off entirely until explicit permission is given? All these extra bells and whistles added to browsers to allow websites to pretend they're 'native apps' should require a very large switch to be thrown from 'safe' to 'unsafe' whenever an application requests such a thing. And what a pdf reader has to do with javascript…

You can disable the PDF reader quite easily:

https://support.mozilla.org/en-US/kb/disable-built-pdf-viewe...

Re: Firefox exploit found in the wild

#39

Post by jonaslejon » Fri, Aug 07, 2015, 10:12 AM UTC

Since the vulnerability is in pdf.js, is the Tor Browser Bundle vulnerable?

Re: Firefox exploit found in the wild

#40

Post by phpmal » Fri, Aug 07, 2015, 10:13 AM UTC

aembleton wrote: post #2

If at all possible it would be worth naming and shaming the advertising network that is allowing this exploit through. Why do advertising networks allow advertisers to exectue Javascript? What need is there for it? Every time one of these exploits that use advertising networks is found, it just increases the value of blockers such as uBlock. Whether you accept adverts or not, you shouldn't have to accept javascript b…

One of the goals of ad networks is to fill as much capacity as possible before relinquishing control to the website owner. The website owner then passes that unused capacity to a chain of competing networks. The last in the chain is usually a poor quality remnant network with junk ads.

The way an ad network fills capacity is by allowing other ad networks to be their advertisers. Those ad networks buy the crappy traffic and fill it with junk ads.

It's those crappy ads that look bad and may have scams attached to them - they get passed around so much that they can get lost in the system.

That said, premium campaigns can also have bad ads. Like advertisers pretending to be premium clients but under the right conditions (like geolocation, date, time, viewing host) the ads will turn bad. It's a game of cat and mouse, and those ad networks are more geared for sales.