New vulnerability discovered for Firefox 3.5.1 (Update)

by Steve Ragan - Jul 18 2009, 18:30

Update:

New vulnerability discovered for Firefox 3.5.1(IMG:J.Anderson)

Mozilla says that the reports from SANS and IBM are incorrect. Based on internal testing, the vulnerability is not exploitable. "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," wrote Mike Shaver on the Mozilla Security Blog."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."Original Article:On Thursday or early Friday, depending on how you look at it, Mozilla released Firefox 3.5.1 to address a vulnerability in the Just-in-Time (JIT) compiler. Now, there are confirmed reports of a second vulnerability, exploit code already published, which affects Firefox 3.5.1, and other versions could be vulnerable as well. The vulnerability was reported to SecurityFocus (BID 35707) on July 15. This morning, a report from SANS Internet Storm Center, followed by an IBM ISS X-Force alert, confirmed that this vulnerability was confirmed present in Firefox 3.5.1. 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 exploit attempts fail, a denial of service scenario. The flaw has posted proof-of-concept code, which can be viewed here. According to several sources, there is no patch at this time for the vulnerability. In addition, this vulnerability was discovered by the same person who published details on the previously patched flaw. According to a comment on SANS ISC, eEye has said that in this case NoScript might not help. "Note: Although Javascript access can be restricted with applications such as the NoScript Add-On, it may still be possible for the browser to be exploited if an untrusted website is loaded (with/without the consent of the user, for example, via XSS or compromised-whitelisted website)"If Mozilla issues a comment or if there is more information to report, we will update this story.

Comment on this Story

Interested in a more interactive TTH? Join our Facebook Group
Want regular updates from The Tech Herald? Follow us on Twitter

Comment on this Story

Note our older Talkback system is still running below. We hope to import existing comments into the new system shortly. Guest posting is still allowed, however, you can now login with any number of social network accounts.

Talkback

Add your comment (no registration required)

page: 1

Giorgio MaoneJul 18th, 2009 - 19:09:20

This 'eEye' is utterly ignorant.
NoScript features the first and best client side anti-XSS protection, therefore it's practically impossible running JavaScript code 'from an untrusted website without the consent of the user'.

Report this comment

B0risJul 19th, 2009 - 18:00:08

Uh, eEye are well-recognised, successful security researchers, responsible for finding several notable vulnerabilities including the one used by Code Red worm. You must be feeling very cocky today to call them 'completely ignorant'!
Someone is certainly ignorant... Of course NoScript won't protect you from *a compromised site on your whitelist*. If a site is on your whitelist, then by your own choice NoScript won't protect you from it.

Report this comment

nemoJul 19th, 2009 - 18:47:41

Apparently this crashes pretty much every browser out there (Chromium, Safari, Firefox) and is just a null pointer exception.

To the reporter who posted this, are you sure this is exploitable with remote code execution?

Because crashing a browser using javascript, while annoying, is not exactly uncommon. Solution for user. Don't go to the bastardly site (and maybe use NoScript).

Report this comment

jasonJul 19th, 2009 - 18:52:46

Usually bad code comes from a different domain. Because there is no reason to load a script from yourbank.com.jijshu965543.cn when you are browsing yourbank.com

Report this comment

Asa DotzlerJul 19th, 2009 - 19:21:34

This is a browser out of memory crash. There is no evidence that this is exploitable while all evidence points to it not being exploitable. Pretty much all browsers crash from this but that doesn’t mean that it’s a security issue.

Report this comment

Mike ShaverJul 19th, 2009 - 22:37:17

This is incorrect. It is neither a stack overflow nor exploitable. Please see the Mozilla Security Blog for more details. (I can't post a link to it here because it is rejected by the comment system, alas.)

Report this comment

MikeJul 21st, 2009 - 21:00:06

It doesn't seem to crash IE8 on my machine. It freeze it for about 10 seconds, But it continue to work fine without crashing.

Report this comment

page: 1

Add your comment (no registration required)

Security

New vulnerability discovered for Firefox 3.5.1 (Update)

Comment on this Story

Talkback

Latest

Latest Articles on Monsters&Critics

In The Tech Herald

Site

The Fine Print