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

231–240 of 277 posts

Re: Firefox exploit found in the wild

#231

Post by ergothus »

All the comments thus far have focused on the un/reasonableness of the vulnerability, plus some potshots at FF.

I've not seen any discussion about how this exploit is targeting dev keys. I find that as a data point that we've turned the corner: The coder in this case decided to grab auth keys/passwords (with a presumably low rate of success).

As logical as it may be (without RCE, not much more they could have done with a higher rate of success), I don't think it'd have been done ten years ago.

Fascinating.

Re: Firefox exploit found in the wild

#232

Post by async5 »

dbbolton wrote: post #217
ck2 wrote: post #208

Earlier quoted context omitted.

SumatraPDF is the only reasonable way to view a PDF safely. http://www.sumatrapdfreader.org/free-pdf-reader.html Not perfect but definitely not adobe or foxit and way safer than viewing in any browser.

What makes Sumatra safer than other FOSS PDF viewers like evince, okular, epdf, etc.?

Market share... and ignorance of users :)

Re: Firefox exploit found in the wild

#233

Post by baghira »

ronjouch wrote: post #198
baghira wrote: post #152

Earlier quoted context omitted.

Ok, I guess that I misread the tone of your post (i.e. we largely agree). I don't however think that the web it that broken without those features (javascript being the harder one to police). Judging from the browsing habits of my family members, they don't spend nearly as much time inside web applications as the HN news cycle would lead me to believe: some news sites, some webmail (and even there, when presented wit…

> None of these uses requires the ability to play quake3 inside firefox, or are really applications inside a webpage. Maybe, for now. But WebRTC/WebSockets have a value proposal for real-time interaction in collaborative office suites. Canvas/WebGL have one for performance in authoring tools and for articles illustrations. Documents are readable in your default serif/sans-serif set, but WebFonts are a good designer/a…

1. Yes, you have higlighted a source of frustration: currently to limit certain features one must either install half a dozen extensions on chromium or firefox, or stick to ESR versions of firefox, or gtkwebkit browsers (which I'm afraid do lag behind the apple upstream when it comes to security fixes). Hopefully with CEF and servo swapping out an engine for another will be easier, so the situation may improve a bit.

In an ideal world, this would be the purpose standards are: all the browsers agree on a set of minimum features, and security conscious users or administrators can decide to stick to that (I have no clue on whether other browser vendors would be interested). This would break websites in a predictable manner. After all sooner or later browser vendors will probably decide to break all tls-less websites. Some websites would be broken, but for people using a screen reader the web is already broken, and at least the would have a clear metric to point at when dealing with banks/news sites/institutions: if it breaks firefox/chrome/safari/edge safe mode, the webdesigner is doing something wrong. Similarly the limit imposed by organizations would help: if you are an entrerprise website you must render correcly in this mode. I'm convinced that administrators enforcing a "no IE policy" on the workplace did help move us away from a world in which frontpage's HTML was acceptable. My parents and users of entreprise workstation don't have browser choice anyway: they cannot install software.

2. Sure, the problem with modes is the problem with the UAC: you end up asking permission so often that you devalue the role of permssions, or you require the user to constantly check the current status of the application (e.g. the lock icon for SSL), which most users won't do. Polaris probably suffers from similar problems, as all "restrictive" extensions do. I'll admit that my solution is squarely aimed at users that cannot switch browser (or cannot switch browser mode), similarly to the gatekeeper role of apple on iphone, only giving the power to switch to administators/technically advanced users, which apple does not.

Re: Firefox exploit found in the wild

#234

Post by async5 »

currysausage wrote: post #229
async5 wrote: post #99

Earlier quoted context omitted.

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

Guess I will click-to-play PDFium, like all other plug-ins. Thanks!

There is also https://chrome.google.com/webstore/detail/pdf-viewer/oemmndc... :)

Re: Firefox exploit found in the wild

#235

Post by TazeTSchnitzel »

ck2 wrote: post #208
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…

SumatraPDF is the only reasonable way to view a PDF safely. http://www.sumatrapdfreader.org/free-pdf-reader.html Not perfect but definitely not adobe or foxit and way safer than viewing in any browser.

Sumatra is written in a memory-unsafe language and runs unsandboxed natively. Why should I trust it?

Browsers are at least sandboxed and have heavily scrutinised codebases.

Re: Firefox exploit found in the wild

#236

Post by TazeTSchnitzel »

andrepd wrote: post #189
jebblue wrote: post #158

Browsers are supposed to browse that's all. More and more stuff like this will come up with HTML5/JavaScript and people will begin to wonder why the world is jumping through all the JavaScript hoops to build a web app that is essentially a rich client app when they could use tools that are designed for that. Are they more or less secure, neither, once you can touch the user's filesystem the risk is the same which is…

What is browsing, then? Read-only? Are forums browsing, or interactive apps? Where do you draw the line? I'm all for less bloat, and I can't figure why would a browser double as a PDF reader, for instance, when a native app is invariably faster, more feature-rich, more customisable and more secure. However, it's difficult to draw a concrete line between plain browsing and web apps.

> I can't figure why would a browser double as a PDF reader, for instance, when a native app is invariably faster, more feature-rich, more customisable and more secure.

A native app is less secure. They're all written in memory-unsafe languages, are not guaranteed to be up-to-date, and do not run sandboxed. Integrating a JS PDF viewer into the browser hurts performance, but it's more convenient (no separate app to open, can start reading before it finishes downloading), and much less likely to be a security risk.

Re: Firefox exploit found in the wild

#237

Post by coffeeaddicted »

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

With external pdf-viewers the browser asked each time before downloading and showing a pdf. Now it displays pdf's by default. That's why an exploit could sneak through as advertisment. It couldn't have done that before.

Re: Firefox exploit found in the wild

#238

Post by tacone »

> Yesterday morning, August 5, a Firefox user informed us that an advertisement on a news site in Russia was serving a Firefox exploit that searched for sensitive files and uploaded them to a server that appears to be in Ukraine.

Which russian website, excuse me? Why not share the name?

Re: Firefox exploit found in the wild

#239

Post by yellowapple »

slasaus wrote: post #196
fluidcruft wrote: post #97

Earlier quoted context omitted.

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.

"making firefox less insecure": http://marc.info/?t=141616714600001&r=1&w=2 and for those who think lynx is a more secure alternative, read this thread: http://marc.info/?l=openbsd-tech&m=140516601718662&w=2

That flamewar there in the lynx thread sure looked fun :)

Re: Firefox exploit found in the wild

#240

Post by rockdoe »

sp332 wrote: post #179
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

The first page says: "There are two times when Firefox will communicate with Mozilla’s partners while using Phishing and Malware Protection. The first is during the regular updates to the lists of reporting phishing and malware sites. No information about you or the sites you visit is communicated during list updates. The second is in the event that you encounter a reported phishing or malware site. Before blocking t…

It is? Same FAQ page you listed:

"When you download an application file, Firefox will verify the signature. If it is signed, Firefox then compares the signature with a list of known safe publishers. For files that are not identified by the lists as “safe” (allowed) or as “malware” (blocked), Firefox asks Google’s Safe Browsing service if the software is safe by sending it some of the download’s metadata."

Post reply on HN