0day vulnerabilities in Firefox, with source

It seems like Internet Explorer has been given a lot of heat lately with a rash of 0day vulnerabilities, and if you do use IE then do yourself a favor and visit ZERT, but has the time come for Firefox to shine as well? If you take a brief look at the list of publicly known vulnerabilities in Firefox it should come as no surprise that there will naturally be a slew of undisclosed vulnerabilities as well.

At the ToorCon 2006 conference, Mischa Spiegelmock and Andrew Wbeelsoi made a point out of demonstrating a live exploit running in Firefox 1.5.0.7. Their main motivation was appareantly to create bot networks for their personal use, or in their own words – “communication networks for black hats”.

Spiegelmock claims that the Javascript implementation in Firefox is a “complete mess”, stating further that “It is impossible to patch”. Personally, I disagree – though perhaps only on the finer points of those statements. Browsers are inherently insecure by design, not because of any one vendors particular implementation. Their objective is to retrieve arbitrary textual content from an untrusted network location, parse that text into a set of processing instructions and then render a visual representation of
the document. Browsers are semi-compilers with a range of legacy deviations that all add up to enormously complex parsing environments, the perfect hunting ground for vulnerabilities caused by developer oversight. Adding Javascript on top of that only increases the complexity linearly instead of exponentially.

These kinds of vulnerabilities will naturally happen when any given environment becomes too complex to comprehend in a single state of mind. However, if the history of security handling at Mozilla is any pointer, they will be fixed within days – at most a week. Unlike Microsoft, Mozilla actually has a framework in place for quickly and efficiently distributing security patches within days, a framework which can only exist because, unlike Microsoft, Mozilla does not have any paying customers to hackle with over issues such as backwards compatibility and functionality regressions. Mozilla faces emotional instead of monetary damages if they screw up a security patch, and Mozilla has a lot of goodwill to bargain with.

Until Mozilla releases those patches we are left in the dark about what those vulnerabilities are and what their impact might be – or are we? Mozilla does prevent public access to its security related items on Bugzilla to prevent active exploitation in the wild, but in this case we already know that these vulnerabilities are being actively exploited; hence, we are curious to see what the fuzz is all about, but how can we do that?

It’s simple, all of the Mozilla source code is in CVS and all commits are followed by a comment that details what Bugzilla ticket it fixes and by correlating this with the recently opened Bugzilla cases that are non-public we can determine which commits are security fixes. Therefor, let’s take a look at the commits in the last week:

http://bonsai.mozilla.org/cvsquery.cgi?dir=mozilla%2F&date=week
The most likely commits are the following 3:

#353249 [Core:JavaScript Engine]-(undisclosed security fix) [All]
https://bugzilla.mozilla.org/show_bug.cgi?id=353249
CVS DIFF containing the vulnerability details
#354924 [Core:JavaScript Engine]-(undisclosed security fix) [All]
https://bugzilla.mozilla.org/show_bug.cgi?id=354924
CVS DIFF containing the vulnerability details

#354945 [Core:JavaScript Engine]-(undisclosed security fix) [All]
https://bugzilla.mozilla.org/show_bug.cgi?id=354945
CVS DIFF containing the vulnerability details

Bugzilla #353249 deals with access flags in jsxml.c, which contains the processing code for E4X (EcmaScript 4 XML).

Bugzilla #354924 deals with flags in jsinterp.c on how to import properties that refer to local variables or formal parameters of a function activation that bybass the normal scope chain lookup.

Bugzilla #354945 is the real kicker, and implements a fairly large change to how native iterators are handled.

The common ground for these 3 vulnerabilities seem to be scope chain lookups that have to ensure whether the context of code A can interact with code B. Just as Internet Explorer has a “special place” for running unrestricted content (the My Computer and Trusted Sites zones) Mozilla has the Chrome context, which exists because the browser itself is built upon the very technologies that it contains and these have to interact occassionally. When content from the great big “Internet” zone gains access to the Chrome context it can do anything the browser itself can do, such as read or write files, send and receive network traffic or execute code. The really great thing about the Chrome context is that, unlike binary platform-dependent ActiveX controls in IE, it is plaintext and cross-platform due to the enormous functionality library in Mozilla’s XUL.

Will the revelation of 0day vulnerabilities in Firefox make a huge impact on how we perceive open source? I hope not, by now we should have come to terms with the fact that all software has security vulnerabilities, and, just like Internet Explorer, Firefox has now become a target with a sufficient large userbase that people care to dig deeper into it.

Print Friendly, PDF & Email