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 18.104.22.168. Their main motivation was appareantly to create bot networks for their personal use, or in their own words – “communication networks for black hats”.
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:
The most likely commits are the following 3:
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.