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

61–70 of 277 posts

Re: Firefox exploit found in the wild

#61

Post by _wmd »

creshal wrote: post #58
cesarb wrote: post #52

How many PDF.js security vulnerabilities have been found so far? A quick Google search found only four: https://www.mozilla.org/en-US/security/advisories/mfsa2013-9... (another local file disclosure) https://www.mozilla.org/en-US/security/advisories/mfsa2015-3... (needs to be "combined with a separate vulnerability" to be exploitable) https://www.mozilla.org/en-US/security/advisories/mfsa2015-6... (needs to be "combi…

> It still is looking better than the plugin it replaced. Not for long if this keeps up…

For comparison, NIST NVD lists 445 CVEs for Acrobat, or at least 17 per year since introduction. However CVEs haven't been maintained since the early 90s, so that number should be much higher. I think pdf.js does just fine.

Re: Firefox exploit found in the wild

#62

Post by ZeroGravitas »

snvzz wrote: post #28
jacquesm wrote: post #8

Earlier quoted context omitted.

I'm roughly in the same boat as you but what I don't get is if your work is that sensitive then why don't you run with at least ghostery, umatrix and adblock on your machine? The last thing I need is to have to contact a customer to tell them their data might have escaped my desktop computer because I took my browser to some unsafe site. Also: start your browser in a VM.

Rather than ghostery: https://www.eff.org/privacybadger

Not compatible with Firefox 40?

Re: Firefox exploit found in the wild

#63

Post by _wmd »

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…

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 want a browser that has some notion of "local file context" you should just sell your laptop and go live in a cave. FWIW the entire Firefox UI and every plugin for it is _written_ in Javascript served from local disk. Chrome, Safari and IE aren't far behind

Re: Firefox exploit found in the wild

#65

Post by digital-rubber »

jacquesm wrote: post #12
Silhouette wrote: post #10

Earlier quoted context omitted.

I do run with the browser locked up tight. It runs basically no plug-ins by default, and I have multiple privacy and blocker plug-ins active. I also have a complete log of every piece of software and update to it that has been manually/voluntarily installed in the entire lifetime of every affected system. What I don't know right now is whether any of that actually helps me in this case.

I really recommend you use a VM for browsing, or even a physically separate computer from the one that you keep your sensitive stuff on. It's a pain but it's a lot better than any of the alternative scenarios.

unfortunately already too many issues with VM to use that as a safeguard. Better to use a separate computer, hardware.

Re: Firefox exploit found in the wild

#67

Post by sanxiyn »

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 uninstalled PDF viewers and always use pdf.js to view PDFs these days.

Re: Firefox exploit found in the wild

#68

Post by fukusa »

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 the news site was compromised. It could have been deliberately injected by the website operators, but I highly doubt it. The exploit targeted developers or tech-savvy people. On Linux, it targeted the contents of the ~/.ssh directory and some other sensitive files. I should say that I am not a security expert and I came across this 0-day by accident.

Re: Firefox exploit found in the wild

#69

Post by JupiterMoon »

jacquesm wrote: post #16
JupiterMoon wrote: post #13

Earlier quoted context omitted.

Given that the company that makes the closed source Ghostery add on make their living selling user data I was say that for sensitive work this addon should probably be avoided. Some combination of script and adblocker would probably be a good idea though.

If you're referring to 'Ghostrank' that's opt-in and off by default. If there is something else going on then I'd really like to know about it! Their sources are open and you can inspect them to make sure they don't do anything nefarious so that would have to be quite an elaborate play on their part with the downloads being different than the published source in critical parts.

It is closed source. https://en.wikipedia.org/wiki/Ghostery

Re: Firefox exploit found in the wild

#70

Post by baghira »

stingraycharles wrote: post #50
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'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 bilions features? Heck, I've also noticed that many users will skim the file and then forget to save it, so it doesn't even help less tech savy users.

There are genuine improvement in the new web technologies, but they are mixed with a lot of stuff that simply does not belong there, and with the insufferable attitude "you can do in javascript, hence you should it in javascript" (I'm not criticizing you, eh, and there is some security argument to be made).

Post reply on HN