How EgotisticalGiraffe was fixed

In October, Bruce Schneier reported that the NSA had discovered a way to attack Tor, a system for online anonymity.

The NSA did this not by attacking the Tor system or its encryption, but by attacking the Firefox web browser bundled with Tor. The particular vulnerability, code-named “EgotisticalGiraffe”, was fixed in Firefox 17, but the Tor browser bundle at the time included an older version, Firefox 10, which was vulnerable.

I’m writing about this because I’m a member of Mozilla’s JavaScript team and one of the people responsible for fixing the bug.

I still don’t know exactly what vulnerability EgotisticalGiraffe refers to. According to Mr. Schneier’s article, it was a bug in a feature called E4X. The security hole went away when we disabled E4X in Firefox 17.

You can read a little about this in Mozilla’s bug-tracking database. E4X was disabled in bugs 753542, 752632, 765890, and 778851, and finally removed entirely in bugs 833208 and 788293. Nicholas Nethercote and Ted Shroyer contributed patches. Johnny Stenback, Benjamin Smedberg, Jim Blandy, David Mandelin, and Jeff Walden helped with code reviews and encouragement. As with any team effort, many more people helped indirectly.

Thank you.


Now I will write as an American. I don’t speak for Mozilla on this or any topic. The views expressed here are my own and I’ll keep my political opinions out of it.

The NSA has twin missions: to gather signals intelligence and to defend American information systems.

From the outside, it appears the two functions aren’t balanced very well. This could be a problem, because there’s a conflict of interest. The signals intelligence folks are motivated to weaponize vulnerabilities in Internet systems. The defense folks, and frankly everyone else, would like to see those vulnerabilities fixed instead.

It seems to me that fixing them is better for national security.

In the particular case of this E4X vulnerability, mainly only Tor users were vulnerable. But it has also been reported that the NSA has bought security vulnerabilities “from private malware vendors”.

All I know about this is a line item in a budget ($25.1 million). I’ve seen speculation that the NSA wants these flaws for offensive use. It’s a plausible conjecture—but I sure hope that’s not the case. Let me try to explain why.

The Internet is used in government. It’s used in banks, hospitals, power plants. It’s used in the military. It’s used to handle classified information. It’s used by Americans around the world. It’s used by our allies. If the NSA is using security flaws in widely-used software offensively (and to repeat, no one says they are), then they are holding in their hands major vulnerabilities in American civilian and military infrastructure, and choosing not to fix them. It would be a dangerous bet: that our enemies are not already aware of those flaws, aren’t already using them against us, and can’t independently buy the same information for the same price. Also that deploying the flaws offensively won’t reveal them.

Never mind the other, purely civilian benefits of a more secure Internet. It just sounds like a bad bet.


Ultimately, the NSA is not responsible for Firefox in particular. That honor and privilege is ours. Yours, too, if you want it.

We have work to do. One key step is content process separation and sandboxing. Internet Explorer and Chrome have had this for years. It’s coming to Firefox. I’d be surprised if a single Firefox remote exploit known to anyone survives this work (assuming there are any to begin with). Firefox contributors from four continents are collaborating on it. You can join them. Or just try it out. It’s rough so far, but advancing.

I’m not doing my job unless life is constantly getting harder for the NSA’s SIGINT mission. That’s not a political statement. That’s just how it is. It’s the same for all of us who work on security and privacy. Not only at Mozilla.

If you know of a security flaw in Firefox, here’s how to reach us.

3 Responses to How EgotisticalGiraffe was fixed

  1. Hmm… XML is a huge horrible spec, so I wouldn’t be surprised if giving JavaScript access to a “real” parser caused security issues of some kind. I recall the usual attack to try is to embed XML document links so that the parser downloads additional data from a different location. A neat way to get around naive “does this XML document contain any FormatDisk tags? – ok save it to disk” type checking.

    Interesting question how it would subvert TOR, though… Maybe the included XML file will be cached and later reused when TOR is disabled?

  2. > I’ll keep my political opinions out of it.

    I would love to hear your political opinion on this because it is very important to know how someone who is working on the security backend of FF ticks.

  3. DDD: the problem with E4X wasn’t parsing the XML syntax. XML parsing isn’t completely trivial, but it’s basically a solved problem. The real problems with E4X were the API it exposed for interacting with XML data, and the way it integrated itself into very fundamental parts of the JS language, without realizing the implications of the changes it made. A further problem was that its algorithms weren’t written with an eye toward self-evident correctness by induction, so the spec was in practice littered with type errors.

    (Also worth noting: E4X was purely a language-level construct. There was no way for E4X to download any data. Everything had to be fed into it via script elements, or by the programmer himself — no different from any other JS code. So no worries about the parsing of E4X downloading anything.)

    Throw in that JSON has more or less won as the data interchange format these days, and the real question becomes why we kept E4X as long as we did. In particular we kept it years past the time when SpiderMonkey developers who’d fixed E4X bugs were actively discouraging its being used, or implemented in other engines, because of E4X’s fundamental flaws.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>