Slashdot Mirror
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.
So who's the moron using unbounded buffers?
Great minds think alike; fools seldom differ.
Is this a new copy-and-paste troll? Almost the same post appeared in the Linux kernel exploit article. Apparently some people missed the Defective by Design campaign and are completely unaware that it relates to DRM, not to arbitrary bugs.
I am TheRaven on Soylent News
... and stop using all of your web-apps... sigh...
------ The best brain training is now totally free : )
I don't know anything about JavaScript or Firefox internals, but a public sounding central function call like "DOCUMENT.WRITE" having a length related buffer overflow is just unacceptable. This call is used all the time right? How could this be missed?
Let's just hope that all those eyes are friendly. How many black hats are scouring the source code to generate exploits to sell underground? As quickly as Firefox releases patches, when these bugs aren't reported it's no better than a proprietary browser.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
FTFA: The vulnerability was reported to SecurityFocus (BID 35707) on July 15.
4 days > 24 hours.
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.
document.write = function(){ alert("This website was designed by a fucking idiot."); };
Well, obviously he meant 24 hours after it was posted on Slashdot. As we all know, it's not real until it's on Slahdot.
It's safe to say that the meme has been co-opted. It seems to pop up in a fair number of articles these days.
.. as the horrible language that is JavaScript is extended ever more to try and emulate real desktop applications (and more pervasive advertising).
Mang, sometimes I wish I could still get by with a browser that doesn't support JS at all, but web devs insist on building websites that absolutely require JS. For example the free SMS service for my mobile phone network (Meteor) absolutely won't work with JS disabled.
Really? Taking a look at stories that have the defectivebydesign tag there are DRM stories as you point out. However, look at some of the stories in there:
* Critical security hole in Linux Wi-Fi
* Apple issues patches for 25 security holes
* Very severe hole in Vista UAC design
* Surprise, Windows listed as most secure OS
* Vista worse for user efficiency than XP
* Loophole in Windows random number generator
* Remote exploit of Vista speech control
* SP1 unsuccessful in preventing Vista hacks
* Data loss bug in OS X 10.5 Leopard
And so on. So yes, the majority of stories using the tag are DRM-related but there's an increasing usage towards general-purpose software bugs or exploits as shown by the articles I pointed out.
http://slashdot.org/tags/defectivebydesign
Some stories tagged "defectivebydesign" that are not at all related to DRM:
"Critical Security Hole in Linux Wi-Fi" .MOV + Toshiba + Vista = BSOD"
"Apple Issues Patches For 25 Security Holes"
""Very Severe Hole" In Vista UAC Design"
"MS Responds To Vista's Network / Audio Problems"
"Apple's IPhone 3G Firmware Update Bombs"
"QuickTime
"Vista Slow To Copy, Delete Files"
"Vista Runs Out of Memory While Copying Files"
"Mark Russinovich On Vista Network Slowdown"
"Microsoft Knew About Xbox 360 Damaging Discs"
"Vista Not Playing Nice With FPS Games"
That's as far as I can be bothered to read. Go look at it yourself. That tag is cheerfully applied to many, many stories about Windows or Apple bugs.
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?
If you use firefox, then you are the moron using unbounded buffers.
These recurring requests to turn off something are getting annoying. Why not automate the process? Set up a page somewhere like
www.mozilla.com/firefox/3.5.1/current-safety.txt
which would list something like
javascript: unsafe
java: safe
flash: safe
Then by default your browser would fetch that file and automatically implement Mozilla's recommendation of the day.
So because Firefox was open when it crashed, Firefox must have caused it? Couldn't be that because most people have their browser open 99% of the time chances are that it will be open when something goes wrong?
To say, for the contemporary web, "turn off javascript", is to say, "break everything". If I can't safely use the browser with Javascript, I can't safely use the browser.
After all, FF is open during development, not just after release. 3.5 has been a long time in coming, the code has been out there for lots to see and lots have looked, yet this was missed.
The thing is, open or closed, any major project has a lot of people looking at the code, and at least some of those people, perhaps most, are highly skilled. What this means is that it isn't likely there's an extremely obvious bug in the code. It isn't the sort of thing that someone would look at the source and go "Oh look they forgot to set getHacked = 0," or something like that. If it were obvious, the developers probably would have caught it. Instead the bugs are due to subtle interactions in teh code, that aren't easy to see.
So, more often than not, the way these things get found isn't someone pouring over the code, it is someone trying out attacks on the finished product. They try sending it bad data of various kinds to see how it reacts, or perhaps they see it react in a certain way to good data that gives them an idea how they might craft bad data to exploit it. Whatever the case, they are working on the finished product, and not particularly concerned with the source.
This is why you find bugs even in projects that many people are on, because developing something and looking at the code is real different from trying to exploit the finished product.
The primary difference being that bugs like this Firefox flaw are accidental and unintentional, whereas DRM is quite deliberate hence the "defective by design" nomenclature. That's such a sharp contrast, it's reasonable to assume that someone who fails to notice it is either speaking of what they know nothing about or purposely trolling. In other words, "highly advanced incompetence is indistinguishable from malice."
There were two ideas mentioned by GP, which were the "defective by design" label and the security reputation of IE. It's useful to know where those perceptions come from whether or not you actually agree with them. I'll make a very simplified (and therefore imperfect) summary of what I perceive as their bases.
The only reason why I see such a concept as "defective by design" applied to IE is a vague one. IE (and Microsoft in general) has something of a history of implementing ideas that were predictably unsound, the most notorious of which is probably ActiveX. That's mostly because ideas which are computationally sound are often orthogonal to ideas which are most easily marketed. True to the nature of a corporation, whenever these two are in conflict, the marketing concerns will win. This is where that perception of closed-source (that is, commercial) software that the GP mentioned comes from.
ActiveX is running untrusted code from a hostile network with no sandboxing and with the full privileges of the user running the browser. Before a single line of code is ever written to implement this, you can predict in advance that this is an unsound idea which invites trouble. Microsoft wrote the code and implemented the idea anyway. IMO that was a deliberate business decision because they felt the marketing and promotion of $SHINY_FEATURE would gain them more than they would lose from the PR problems of security issues. Because of how ignorant the general public tends to be about computer security, such decision-making has been largely successful. In other words, the people at Microsoft are not a bunch of idiots who didn't know what they were dealing with. They knew and they made their decision. Still, it's better to call that "faulty design" and "poor priorities" than to hijack a very specific term like "defective by design."
It is a miracle that curiosity survives formal education. - Einstein
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....
A simple heuristic: if you can submit a well-written bug report and at least an attempt is made to fix the issue, it's probably not a design flaw.
It is a miracle that curiosity survives formal education. - Einstein
Fix once, fix forever
The bug is in the Just-in-Time compiler inside of SpiderMonkey (TraceMonkey). This is brand new code as of 3.5.x. Of course there will be a ton of bugs found in it (just like the ton of bugs that have cropped up in SquirrelFish and have been subsequently patched).
I have to wonder why it's taken so long for anybody's security team to look at this code though. You'd think they'd look at this code before release and not after.
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
Worse POC evar
-----
<html>
<head>
<script language="JavaScript" type="Text/Javascript">
var str = unescape("%u4141%u4141");
var str2 = unescape("%u0000%u0000");
var finalstr2 = mul8(str2, 49000000);
var finalstr = mul8(str, 21000000);
document.write(finalstr2);
document.write(finalstr);
function mul8 (str, num) {
var i = Math.ceil(Math.log(num) / Math.LN2),
res = str;
do {
res += res;
} while (0 < --i);
return res.slice(0, str.length * num);
}
</script>
</head>
<body>
</body>
</html>
<html><body></body></html>
This post contains benzene, nitrosamines, formaldehyde and hydrogen cyanide.
This is the reason why I avoid crappy software like Firefox and stick to MSIE! Firefox is riddled with bad, bloated code making it easily subjectable to these types of attacks. On top of that, the development model allows mistakes like this to get into the codebase without proper quality assurance.
If I have to /sarcasm, I will kill you.
But, but, but, that's unpossible!
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
Folks, Noscript will catch most Javascript exploits, but you should have a 'catch net'. AppArmor provides a 'sandbox' around any process you want. Firefox is a good example that I have written a how-to for creating an AppArmor Profile in Ubuntu 9.0.4 Read my blog here Be Safe. Dietrich T. Schmitz
Remember the Debian SSH debacle? Some guy wanted to stop valgrind's whining about uninitialized memory in the SSL key generator, so he helpfully zeroed the buffer in question. Valgrind stopped complaining, but his fix also reduced the entropy used in key generation down to about nothing. For two years, people were generating very weak key-pairs.
I'm not saying valgrind, etc. are bad, only that sometimes they can be misleading.
You did not just say that. Tell me you did not just say that.
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
I'm not aware of any malware having been launched from facebook.com.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
I have to wonder why it's taken so long for anybody's security team to look at this code though. You'd think they'd look at this code before release and not after.
Announcing defects in beta software doesn't get you noticed.
See http://blog.mozilla.com/security/2009/07/19/milw0rm-9158-stack-overflow-crash-not-exploitable-cve-2009-2479/ for more details, including specifics about how the bug affects different platforms and versions (worst case: unexploitable crash in OS X system libraries).
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.