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

111–120 of 277 posts

Re: Firefox exploit found in the wild

#111

Post by hokkos »

fukusa wrote: post #75
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...

In this case, it was disguised as an advertisement but it was not running on an advertisement server. My adblocker did not catch it. It was injected into the page as an iframe twice. Once disguised as an ad ([IP-address]/ad.php), another time with just the IP-address of the server. I guess it was included a second time in case and adblocker catched the first one. Because it doesn't make sense to include the same expl…

How did you detected it ?

Re: Firefox exploit found in the wild

#112

Post by anc84 »

hornbill wrote: post #66

Out of curiosity, how many users will be opening pdf using pdf.js? Is it widely used? I was never comfortable with pdf.js and changed the setting to use the default pdf viewer in all my machines.

> I (...) changed the setting

You can rest assured that 99% of Firefox users won't do that.

Re: Firefox exploit found in the wild

#113

Post by ams6110 »

serve_yay wrote: post #102
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.

I do block JS by default. If it's a site that won't render something readable without JS, I usually just move on. If it's one that I really need to interact with I'll enable it for that site, which does open some risk, but this approach generally makes drive-by exploits less likely.

Re: Firefox exploit found in the wild

#114

Post by zzzeek »

_wmd wrote: post #63
jacquesm wrote: post #19

Earlier quoted context omitted.

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…

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 you don't want a browser that has some notion of "local file context" you should just sell your laptop and go live in a cave.

this is kind of a silly statement. nobody would argue a program shouldn't be able to access local files, in this case, we would presume, PDF content that's been downloaded into a cache. the very simple argument is that the code which deals with opening and reading files from disk should be completely isolated from scripting-language code that runs dynamically in the same object space as the front-end scripting environment. e.g., put the .js in a sandbox by default the way we used to take for granted.

I understand that in the Mozilla suite, this barn door was left open years ago and the horses are far and wide by now.

Re: Firefox exploit found in the wild

#115

Post by TazeTSchnitzel »

realityking wrote: post #91
kevingadd wrote: post #46

Earlier quoted context omitted.

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/ )

It is proprietary, but PDF is the foundation of OS X's graphics, so it's very well-tested.

Re: Firefox exploit found in the wild

#116

Post by rc4algorithm »

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.

Search the OpenBSD mailing list archives. Someone there got it working but ran into some problems.

Re: Firefox exploit found in the wild

#118

Post by baghira »

ronjouch wrote: post #94
anon1385 wrote: post #87

Earlier quoted context omitted.

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

It doesn't help your position the fact that you are unable to express it without belittling anybody who disagrees with you using stuff like "stay stuck in 1992" ("If you don't like America you should go to Russia!").

Also, the links/lynx jokes have really gotten tired, plenty of people browse the web with ublock, no(t)script, webgl and webrtc disabled and so on. The pretense that anybody who tries to retain a modicum of control on what its browser does and does not it a luddist is frankly irritating.

And the whole language debate is completely off point, we have plenty of safe(r) languages for writing stuff, the misguided idea is that the only way to do so is to use javascript and stick the resulting program inside the browser.

Post reply on HN