Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firefox exploit found in the wild

blog.mozilla.org

Post reply on HN
Print view View original

101–110 of 277 posts

Re: Firefox exploit found in the wild

#101

Post by _nedR »

wereHamster wrote: post #21
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…

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.

For windows there is a Sandboxie. http://www.sandboxie.com/

Sandboxie has gotten very good over the years. You can sandbox programs that even run with admin privileges.

edit: Don't think sandboxie can load drivers.

Re: Firefox exploit found in the wild

#102

Post by serve_yay »

lorenzhs wrote: post #55

Once again, this demonstrates that blocking advertisements is a really good idea from an InfoSec perspective. Ad blocking not only abates a nuisance, it's an important security measure. cf https://twitter.com/swiftonsecurity/status/62840155490772582...

By that logic it's more like an argument for disabling JS entirely - there is nothing about this that's specific to ads, and the reporter has speculated that it was placed by an attacker and only disguised as an ad.

Re: Firefox exploit found in the wild

#103

Post by anc84 »

baghira wrote: post #70
stingraycharles wrote: post #50

Earlier quoted context omitted.

You're getting old and grumpy, Jacques, before you know it you will start your sentences with "back in the day..." :) On a more serious note, I guess this is the toll we have to pay for innovation pushing. I can understand the reasoning behind writing everything in JS: it allows you to consolidate a lot of mechanisms in a single platform. Once you have that platform secure, any application you will write will (should…

I disagree that this is innovation. What innovation and what benefits do I reap by using pdf.js? It's slower and has less features than okular. It's stuck inside a firefox window, so I cannot add a window rule for it (barring adding one for firefox in general). The same holds on windows: why would I use pdf.js when there are faster, lighter pdf readers (e.g. sumatra) or the actual adobe acrobat reader and its eight b…

Everyone is punished for Windows' Adobe Reader. I never got it either. PDF is not a web format. I would not want to read doc files in my browser either. Evince(-light) starts up in milliseconds.

Re: Firefox exploit found in the wild

#104

Post by fukusa »

gorhill wrote: post #96
fukusa wrote: post #68

Earlier quoted context omitted.

Hi, I reported this 0-day. It used a PDF.JS same origin policy violation to access local files. You should be safe because you have javascript disabled and pdfjs.disabled set to true. There's no way for the script to run. It was on a international news website operating from Russia. The exploit was not on an ad network. The exploit was simply injected on every news article page through an iframe. Therefore I assume t…

> The exploit was simply injected on every news article page through an iframe Was the "src" of the iframe 3rd-party to the web site? I want to know whether merely blocking 3rd-party iframes would also have prevented the exploit from working even if javascript is not blocked.

Yes it was so it would have prevented the exploit from loading.

Re: Firefox exploit found in the wild

#105

Post by FreeFull »

fluidcruft wrote: post #97
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…

Maybe run it inside a chroot jail? Hmm... that sounds like a good idea just on principle... there goes my morning. Of course, X11 is still a problem.

The Firefox nightlies can run in Wayland without any form of X11 server present.

Re: Firefox exploit found in the wild

#106

Post by anc84 »

mbq wrote: post #73
satai wrote: post #29

Earlier quoted context omitted.

Docker is not secure enough (it can help but it's not designed to be bulletproof). MAC (GRsecurity...) can be considered the "right" solution. Or just give up and go QuubeOS ;)

Why, docker-initiated chroot would prevent FF from acessing any not-FF+libs files, including which this malware steals; on Qubes it would have access to everything user-readable in the AppVM, which may include some secrets as Qubes workflow involves user-supervised copying files across VMs. Obviously docker, as opposed to Qubes, won't stop more complex malware that exploits the kernel.

From all I have heard, docker is not even secure enough to let user A do things in dockerthingyA and user B in dockerthingyB. From what I was told, user A could easily break out into dockerthingyB and maybe even the host. Are you sure it really is not possible short of exploiting the kernel (or docker I guess)?

Re: Firefox exploit found in the wild

#107

Post by drvortex »

smcl wrote: post #11
drvortex wrote: post #9

Why is anyone still using this browser anyway? Firefox is the new IE6.

"...the new IE" has been thrown about so much it is basically an empty statement I'm afraid https://www.google.com/webhp?q=%22chrome+is+the+new+IE%22 https://www.google.com/webhp?q=%22firefox+is+the+new+IE%22 https://www.google.com/webhp?q=%22safari+is+the+new+IE%22

If you had taken a moment to actually scan those search results, you would have realized that "Chrome is the new IE" is typically a reference to its ubiquity.

Safari and Firefox is typically called the new IE because they are lagging behind the times.

Which is why I said "IE6" in my original comment. The later versions of IE were very decent. They certainly didn't seem like the frozen accident of history - an issue Firefox continues to grapple with.

Re: Firefox exploit found in the wild

#108

Post by anc84 »

rplnt wrote: post #48
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.

Wouldn't selinux be enough? Browsers have no business touching files outside of ~/.mozilla or whatever.

How would you handle uploads or downloads then?

Re: Firefox exploit found in the wild

#110

Post by leni536 »

baghira wrote: post #70
stingraycharles wrote: post #50

Earlier quoted context omitted.

You're getting old and grumpy, Jacques, before you know it you will start your sentences with "back in the day..." :) On a more serious note, I guess this is the toll we have to pay for innovation pushing. I can understand the reasoning behind writing everything in JS: it allows you to consolidate a lot of mechanisms in a single platform. Once you have that platform secure, any application you will write will (should…

I disagree that this is innovation. What innovation and what benefits do I reap by using pdf.js? It's slower and has less features than okular. It's stuck inside a firefox window, so I cannot add a window rule for it (barring adding one for firefox in general). The same holds on windows: why would I use pdf.js when there are faster, lighter pdf readers (e.g. sumatra) or the actual adobe acrobat reader and its eight b…

I have mupdf in firefox (iceweasel) using mozplugger. I could always set it up to not display pdfs, only downlad them, use mupdf through mozplugger or use the builtin pdf.js viewer. Having said that I'm not sure that mupdf is safer than pdf.js, but it's much faster.
Post reply on HN