New Firefox Vulnerability Revealed 250
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.
failed proof of concept (Score:3, Informative)
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.
Re:Defective by design (Score:2, Informative)
Really? Taking a look at stories that have the defectivebydesign tag [slashdot.org] 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.
Not just Firefox? (Score:5, Informative)
No Javascript? No Firefox. (Score:3, Informative)
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.
Re:Unbounded (Score:5, Informative)
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.
Re:That's notthe first time (Score:5, Informative)
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....
Re:You can't be serious! (Score:5, Informative)
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. :(
Re:failed proof of concept (Score:4, Informative)
> It looks like the proof of concept only shows how this could lead to a stack overflow
It actually doesn't even show that, if you try running it under a debugger... It shows a null dereference due to lack of out-of-memory check on an allocation.
Re:Not just Firefox? (Score:4, Informative)
When I tried this, I see Firefox crashing with a null dereference. So not exploitable.
Do you see something different?
Re:That's notthe first time (Score:3, Informative)
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>
Re:Turn off javascript... (Score:5, Informative)
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 [w3schools.com]
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.
Run Linux Firefox with AppArmor (Score:2, Informative)
Re:Not just Firefox? (Score:3, Informative)
Well, the fact that SANS is blindly reposting known-unreliable things like milw0rm postins is something of an event, to me... Forgetting the fact that it tarnishes the reputations of whatever software they falsely accuse of being vulnerable, it leads to SANS being less reliable and less trusted. The whole crying wolf thing.
But yeah, I agree that this "exploit" is nothing of the kind.
Re:You can't be serious! (Score:5, Informative)
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.
Re:That's notthe first time (Score:2, Informative)
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.
bug misreported, not exploitable, not a stack over (Score:3, Informative)
not exploitable (Score:5, Informative)