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 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:

The most likely commits are the following 3:

#353249 [Core:JavaScript Engine]-(undisclosed security fix) [All]


CVS DIFF containing the vulnerability details
#354924 [Core:JavaScript Engine]-(undisclosed security fix) [All]


CVS DIFF containing the vulnerability details

#354945 [Core:JavaScript Engine]-(undisclosed security fix) [All]


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.

  • T.C.

    What’s a sleuth of vulnerabilities? It’s a quantity I’m not familiar with.

  • http://na scripteaze

    What’s a sleuth of vulnerabilities? It’s a quantity I’m not familiar with.

    “sleuth of vulnerabilities”

    When looked up at dictionary.com produces a picture of the microsoft logo :)

  • http://cquirke.mvps.org Chris Quirke

    This made me chuckle…

    “Unlike Microsoft, Mozilla actually has a
    framework in place for quickly and efficiently
    distributing security patches within days…”

    …so what are Auto Updates, MS Update, and all the heavy-duty pro-IT patch distribution systems for, then?

    “…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…”

    …normally it’s “MS doesn’t care because they’re a monopoly and will get paid anyway, so they don’t have to please their customers”.

    Now it’s “Mozilla aren’t beholden to paying customers, so they can Do The Right Thing.”

    Hmm. Code will be code, and can have defects. Firefox should be easier to fix, as it’s a self-contained code base kept distinct from the OS – but if the internal design is sufficiently bad, maybe not.

    Using the same engine to run external scripts as the browser itself may be sufficiently bad design, if it makes it harder to amputate code that is suddenly found to be gangrenous…

  • http://weblogs.mozillazine.org/roadmap Brendan Eich

    The first and third bugs are fixing new-in-Firefox-2 code that is still in beta, or now release candidate state. The patched code was not in Firefox 1.5 or earlier. E4X support was in Firefox 1.5, but the code that created a problem requiring a fix to jsxml.c was not. This shows the difficulty of guessing what code is vulnerable from looking at a patch that fixes a bug.

    The second bug is in old code, dating back to Netscape 4.x, which we will remove as soon as we can. We tried recently, but someone was still counting on it. Compatibility costs. Without opening the bug, I can say that it is unlikely to be exploitable, because the bad addresses that lead to crashes are all read from, not written to, and they are not random: they are function addresses. The crashes are due to misalignment or failure to find valid pointers at those function addresses from which to load dependent data.

    Ask yourself: where are the open IE source code repository and bug database? How do you know the MS team is working as hard as Mozilla people including yours truly are to fix bugs like this (and older ones) in IE? It’s possible that they are — we just don’t know. With Mozilla, although we don’t want to spoon-feed exploits of unpatched bugs to blackhats, we disclose everything in due course. Everything.

    This causes bean-counters to declare us less secure. That’s obviously unproven and unproveable, but also unlikely. More important, if you count days of exposure, we are demonstrably better than other browsers (Opera and Safari are close, IE is not):

    “Weafer also noted that the open-source browser had a decided advantage over Microsoft’s on a time-to-patch criteria. Firefox rivals such IE, Safari, and Opera were patched considerably faster in the first half of 2006 than they were in the last half of 2005, but Mozilla’s beat them all. IE, for instance, had an average window of exposure, the time between an exploit appearing and a fix released, of 9 days, while Mozilla patched in 1 day. (Safari’s window was 5 days, Opera’s was 2.)”

    (Information Week)

    You’re right that browsers are challenging to secure given the high number of dimensions of input features that they parse, combined with the common use of C++ as implementation language. For these two reasons, fuzzing is more productive, than static analysis.

    Given the fact that all browsers must be presumed to have exploitable bugs, which would you rather use: an open source one with an open bug database (modulo sane policy to restrict access until the bug is patched), or one where the vendor has failed to earn the trust of its users before, and is now saying “trust us”?


  • http://weblogs.mozillazine.org/roadmap Brendan Eich

    Sorry about the lack of formatting — wordpress, sigh. Paragraph boundaries should be clear.

    BTW, you must have meant “slew”, not “sleuth” ;-) .


  • Anon

    I appreciate Mischa Spiegelmock and Andrew Wbeelsoi for coming forth with enough information to fix this specific issue.

    However, at the same time I must note that it seems they have implicated themselves to be criminals, and should be tried in court. They admitted to breaking into other people’s computers. And they admitted they have more undisclosed vulnerabilities which they will use for more criminal activity.

    If they did the right thing, they would have netter about $15,000 dollars and the gratitude of the whole Mozilla community and improved the security of tens, or perhaps hundreds of millions of computers.

    Instead they chose to be jerks and criminals.

  • biocarbon

    You’re forgetting a few major points:

    1 – andrew was obviously tripping on psychadelics

    2 – mischa was acting like a tard because he was dressed like a chav.

    3 – their entire talk was a bait for trolls like you.

    jerks? yeah, probably. criminals? it was california, timothy leary wanted to dump lsd in the water supply here…

  • Pingback: Microsoft Most Valuable Professional

  • Pingback: Spyware Sucks

  • grutz

    That was pretty much the premise of their talk: stop disclosing shit or get your azz shot down. It was hilariously over the top!

    In a few days (or shorter) you may be able to watch the talk on google video for a few bucks or bug your friends now who have copies of the dvd.

  • Sam Spade

    Window Snyder comments further:

    “So far we’ve been able to reproduce a denial of service issue based on the information they gave during their talk. In some cases this causes a crash based on an out of memory error. Based on the information we have at this time we have not been able to confirm whether an attacker can achieve code execution. We’re still investigating and we’ll keep you updated.”

  • Pingback: Weblog de Mauricio (W.O.L.F.) R. Arreola González

  • Thor Larholm

    Of course I meant slew instead of sleuth ;)

    I’m also looking hard for any exploitable bug, but at the moment I am leaning more towards this simply being an out-out-memory crash and the presenters simply being on crack.

  • http://networksecurity.typepad.com/ Juha-Matti

    There is a CNET TV Video entitled “Hackers claim Firefox zero-day flaw”
    about the presentation available:

  • LR

    We have have been duped. PCWorld has this to say about these hackers. It was all a joke!


  • http://digi.whiteacid.org/ digi7al64

    Taken from http://www.heise-security.co.uk/news/78970

    Claimed security hole in Firefox “just a joke”

    The allegedly critical hole reported yesterday in Firefox’s JavaScript implementation has turned out, not surprisingly, to be a hoax. Mischa Spiegelmock, who made the claim at the Toorcon hacker conference, told Mozilla’s security chief Window Snyder, “The main purpose of our talk was to be humorous.”

    While it is possible to create a stack overflow, the only result he has been able to produce is a browser crash. Neither he, nor anyone else, has managed to execute code via this hole. Spiegelmock claims to know nothing about the other 30 holes reported in the media. The Mozilla team nevertheless plans to look into the matter in order to detect and remedy any flaws.

  • Sam Spade


    “I do not have 30 undisclosed Firefox vulnerabilities, nor did I ever make this claim. I have no undisclosed Firefox vulnerabilities. The person who was speaking with me made this claim, and I honestly have no idea if he has them or not.”

    Pay particular note to the statement “I honestly have no idea if he has them or not”.

    In short, all we have here is one of the kids getting cold feet (probably ’cause his employers were giving him hell) and dumping all the blame on his buddy Andrew.

  • http://gameburn.org Darius

    Help me please…
    I just installed Firefox 2.0, and all of a sudden, my username/password isn't being inserted in the signon window (it always was before). I tried the usual suspects–I did not mistakenly tell FF not to remember the password for this site; and I also tried the remember password bookmarklet, but all to no avail–FF will not ask me to remember this password. What do I need to do to get around this?

  • http://geraldlevert.blogs.ie Zachariah

    Please add firefox cookies/bad web sites immunization in next version!
    Firefox 2 cannot reject third party cookies!!!!!!!!