New Firefox Vulnerability Revealed
Not long after Firefox 3.5.1 was released to address a security issue, a new exploit has been found and a proof of concept has been posted. "The vulnerability is a remote stack-based buffer-overflow, triggered by sending an overly long string of Unicode data to the document.write method. If exploited, the resulting overflow could lead to code execution, or if the exploit attempts fail, a denial-of-service scenario." It's recommended that Firefox users disable Javascript until the issue is patched, though add-ons like NoScript should do the trick as well (unless a site on your whitelist becomes compromised).
Update: 07/20 00:09 GMT by KD : An anonymous reader informs us that the Mozilla security blog is indicating that this vulnerability is not exploitable; denial of service is as bad as it gets.
Update: 07/20 00:09 GMT by KD : An anonymous reader informs us that the Mozilla security blog is indicating that this vulnerability is not exploitable; denial of service is as bad as it gets.
It looks like the proof of concept only shows how this could lead to a stack overflow. There is no concept about how this could lead to code execution, which makes this just just another way to crash a browser.
Crashing browsers is of course potentially a problem, but it quite boring while there are still so many ways to do real exploits.
The proof of concept has crashed every browser I've tried it on; Firefox (obviously) (and the 3.6 nightly), Epiphany, Chromium, Opera and Android Browser. So is Firefox the only browser that is exploitable during the crash or other browsers affected?
This is another, different bug than the one talked about in the first link. None of the other links specify whether this second bug is from the JIT or not.
Nerd rage is the funniest rage.
Have you tried the POC? Ideally under a debugger? It's a null-dereference crash due to failure to check an allocation for out-of-memory conditions. It's not exploitable, as far as I can see. And it's not a stack buffer overflow, by any means.
It'd be nice if these various security advisory services actually double-checked milw0rm postings before echoing them. Half the ones I've seen are in fact crashes, but not the sort the poster claims and not exploitable....
It's not a buffer overflow. It's a missing OOM check leading to a non-exploitable (well, if your kernel is sane; some Linux versions are not) null-dereference crash.
Note also that the article linked to is misreporting this in other ways as well; unfortunately I'm not at liberty to go into details on that yet. :(
Looking at W3Schools stats on it it's about 5%. I've seen some stats suggest as high as 16% around 3 years ago:
http://www.w3schools.com/browsers/browsers_stats.asp
I feel Javascript is an important technology and rather than fucking around with all the proprietary crap like Flash we should be strengthening Javascript so it's more secure and more useful, in fact, a lot of browser vendors seem to be doing this, and those Chrome demos posted a few months back were agood example.
But I also think it's silly to assume and design for Javascript unless Javascript is the whole point of your site. There's so many sites out there that use Javascript for things like drop down menus and sometimes even positioning where CSS would suffice and not require Javascript support it's silly. To turn away 1 in 20 users doesn't seem the brightest idea unless you're building a web application where absolutely the only way to do what you want to do is to use Javascript.
Javascript shouldn't be a requirement for the vast majority of the web, only for those sites that truly need it.
Ok, here's the full deal:
1) The crash is not exploitable, for anyone who's been able to reproduce it so far.
2) The crash is in system text-rendering libraries (which apparently don't check for
out-of-memory much), not in Firefox code, for everyone who's been able to
reproduce it so far.
See what Mozilla has to say: http://blog.mozilla.com/security/2009/07/19/milw0rm-9158-stack-overflow-crash-not-exploitable-cve-2009-2479/ In the last few days, there have been several reports (including one via SANS) of a bug in Firefox related to handling of certain very long Unicode strings. While these strings can result in crashes of some versions of Firefox, the reports by press and various security agencies have incorrectly indicated that this is an exploitable bug. Our analysis indicates that it is not, and we have seen no example of exploitability. On Windows, Firefox 3.0.x is terminated due to an uncaught exception during an attempt to allocate a very large string buffer; this termination is safe and immediate, and does not permit the execution of attacker code. In Firefox 3.5.x on Windows, the allocations are more robustly checked and no crash will result. On the Macintosh in Firefox 3.0.x and 3.5.x, a crash occurs inside the ATSUI system library (part of OS X), due to what appears to be a failure to check allocation results. This issue is likely to affect any application using the recommended text-handling libraries on OS X. We have reported this issue to Apple, but in the event that they do not provide a fix we will look to implement mitigations in Mozilla code. We recommend that other developers who use these libraries consider a similar practice, and we have added mitigations in the past for similar bugs in these libraries. As a result of our analysis, we do not believe that this represents an exploitable vulnerability in Firefox. Further, we believe that the IBM report is in error, and that the severity rating in the National Vulnerability Database report is incorrect. We have contacted them and hope to resolve the inaccuracies shortly.