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

91–100 of 277 posts

Re: Firefox exploit found in the wild

#91

Post by realityking »

kevingadd wrote: post #46
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…

Every major browser has a built-in PDF viewer (except maybe Safari? I don't own a mac). Mozilla's is the only one that's written in JS. The rest are proprietary native blobs. There have been security vulnerabilities (significant ones) found in the native PDF viewer blobs before, so given the choice between a same-origin policy breakage in pdf.js and an exploit in a native PDF viewer that can own my entire machine, I'…

> except maybe Safari? I don't own a mac

Safari uses the same library as Apple's Reader. So it's a proprietary native blob.

Edit: While Chrome uses a native blob, I believe it's not proprietary. I think they use pdfium (https://pdfium.googlesource.com/pdfium/)

Re: Firefox exploit found in the wild

#92

Post by blfr »

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.

Wouldn't this prevent you from opening local .html files?

Re: Firefox exploit found in the wild

#94

Post by ronjouch »

anon1385 wrote: post #87
_wmd wrote: post #63

Earlier quoted context omitted.

You haven't the slightest understanding of software security, PDF.js was written to replace a component authored in a memory-unsafe language for which exploits were being found at a rate measured in tens per year. Since introduction PDF.js has only had 2 holes that were directly exploitable, neither leading to remote code execution which was the default behaviour for pretty much any bug found in Acrobat. If you don't…

If large amounts of code written in memory unsafe languages is such a concern then Mozilla should immediately stop adding large numbers of highly complex new features implemented in unsafe code to Firefox every year, mostly to do things that have absolutely nothing to do with displaying web pages but are enabled by default for political reasons. Just like switching to PDF.js was a decision taken to try and reduce the…

> (a) If large amounts of code written in memory unsafe languages is such a concern then Mozilla should immediately stop adding large numbers of highly complex new features implemented in unsafe code to Firefox every year,

> (b) ... mostly to do things that have absolutely nothing to do with displaying web pages but are enabled by default for political reasons.

(a) Mozilla is working on adding/replacing parts of Firefox with a language emphasizing security (among other things). First Rust push in Firefox landed a Rust mp4 parser [1], on 2015-06-17. Others will come; in the meantime, the world keeps turning, and users / web. developers expect these new web features, which Moz devs implement with the infrastructure they have and know. They're not going to cross their hands and declare a moratorium until Rust (or other security-mitigating features/changes) are fully integrated.

(b) Not sure what you mean by political reasons and maybe you want to stay stuck in 1992, but I don't, and like many users I do want "webgl, webrtc, webfonts, webm, websockets, new css features and so on" .

EDIT I'd have added "You can install links if you want a simple browser letting you read static html documents", which you would have answered with "But I can't, every website require these features now", to which I'd have answered "a. Yeah, not everyone (that's an understatement) does progressive enhancement, but ultimately b. The times they are a-changing"

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1175322

Re: Firefox exploit found in the wild

#95

Post by chippy »

johnnydoebk wrote: post #42

Well, sending some user files to Ukrainian server is a bug. But sending hashes of your downloads to Google [1][2] is a feature, right? 1. https://support.mozilla.org/en-US/kb/how-does-phishing-and-m... 2. https://bugzilla.mozilla.org/show_bug.cgi?id=1138721

Is this the list?

https://dxr.mozilla.org/mozilla-central/source/toolkit/compo...

Just executables, identified by file extension and if you are on Windows, .zip files as well.

Re: Firefox exploit found in the wild

#96

Post by gorhill »

fukusa wrote: post #68
Nanzikambe wrote: post #32

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 Russ…

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.

Re: Firefox exploit found in the wild

#97

Post by fluidcruft »

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.

Re: Firefox exploit found in the wild

#99

Post by async5 »

currysausage wrote: post #74

Semi off-topic: What does the security track record of Chrome's integrated PDF viewer (PDFium) look like? Should I make it Click-to-play or is it about as secure as any other part of the browser? Edit: NVD does list a bunch of vulnerabilities with "PDFium" in them [1], and I guess there are a few more from when it wasn't called PDFium yet, but I'm curious as to how an expert would interpret these numbers. [1] https:/…

And even latest here http://googlechromereleases.blogspot.co.il/2015/07/stable-ch... - 5 of them has pdfium

Re: Firefox exploit found in the wild

#100

Post by wtbob »

drvortex wrote: post #9

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

> Firefox is the new IE6.

That really is nonsense. Firefox is standards-compliant; it's multi-platform; and it works.

I have major issues with its direction (the gelding of its sync service was particularly galling), but it's still the best browser out there.

Post reply on HN