Mozilla Backsliding on Security?
Before Firefox’s numbers were sitting at around 10%, there was the question that spawned its popularity: what can we do about Internet Explorer? It was many months after that before IE emerged from a torrent of unpatched exploits and most of the credit for that belongs to (surprise) a dog-slow patch process in Redmond.
While it’s beyond naive to make the unqualified assertion that a product is secure (or, unbreakable, if you’re Larry Ellison), the marketing behind Firefox was really clever. The strategy was, essentially, blame it all on ActiveX. I, like most, find the notion of mixing web and system code (as MS has done with ActiveX) to be a terrible idea. It ends up producing security holes because of code that was never meant to touch anything remotely connected to the web. ActiveX is also a persistent reason why users have to run as administrators for simple web plugins like Flash Player to install. ActiveX alone, however, is not the reason that IE is insecure.
Reasons for the insecurity of IE6 include the excess of active content permitted to ‘local’ material (which XP SP2 band-aids fairly well), a poorly-done same-origin enforcement model, URL parsing that is prone to hackish manipulations and a renderer that is generally too prone to buffer overruns. Firefox has its own bag of architectural deficiencies, though: the software installation feature is protected only by a security model about as weak as IE’s ‘zones’ and the internal APIs for managing all sorts of different data types are prone to overflows and memory revelation exploits. Firefox’s only real design advantage lies in its disassociation from the operating system it runs on. Though it’s a substantial advantage because it means Firefox doesn’t require system-level software installations to support enhanced content, most Windows users (who run as administrators for everyday use or are on locked-down corporate desktops) won’t notice.
The major advantage that Firefox has (I’ve written about it before) is in being far more nimble than its monopolistic opponent. The nine-day performance that Redmond put on for us with the WMF patch (a record for Microsoft) doesn’t seem all that amazing when fixes are made available for competing open-source products in that timeframe any time there’s a zero-day issue. Microsoft also maintains the idealistic fiction that prioritization of bug fixes can extend to taking eternities to patch issues that seem minor at the time. As we saw on DOM, it gets them burned from time to time.
Mozilla is at a critical juncture, now. The challenge it faces is continuing to promote its technology in a climate where an onslaught of zero-day exploits for Internet Explorer has tamed and a climate where Firefox faces just as much scrutiny as the competition. The fear-based marketing that drove Firefox to popularity is not anywhere near as effective now as then.
Firefox users are getting information poured on them from all directions that says that there are more vulnerabilities in Firefox and that the vulnerabilities that are there are qualitatively more serious. Mozilla’s reaction appears to be downgrading the severity of questionably-exploitable bugs. This strategy of downplay is extremely disappointing to me. Over the short term, it’s a cheap-shot way to get the statistical edge (perhaps even the playing field is more accurate), but over the long-term, it seriously undercuts the idea that Mozilla is “serious about security” (to quote its security page) any more than its well-endowed competitor.
Take, for instance, the 126.96.36.199 release (whatever happened to revision numbers?) on Wednesday. Eight different advisories (comparable to the different vulnerabilities listed in Microsoft bulletins) are shown as fixed. Until you see that one of them (MFSA-2006-01) actually deals with two issues (one of which is an apparent regression introduced since the 1.5 branch-point). Also of note that is that none of these issues were fixed in Thunderbird or the 1.0.x series of Firefox. I also was unable to track down any information that indicates these issues were plugged in the Mozilla Suite, which includes both browsing and mail-reading components. The disorganization has its parallels (Microsoft Service Pack releases, anyone?) but it is discouraging. Better response on security is one of the main reasons I prefer Firefox.
More disconcerting is that only one of the eight advisories receives a rating of “critical” (MFSA-2006-05) and none were given “high” risk ratings. This in spite of the fact that four of these advisories (MFSA-2006-06, MFSA-2006-04, MFSA-2006-02 and MFSA-2006-01) deal with potentially-exploitable vulnerabilities that may enable arbitrary code execution. Those issues received a relatively soft “moderate” rating. While I recognize that there’s a desire to avoid liberal use of the “critical” rating (for statistical and practical reasons), low-interaction, potentially-exploitable scenarios like these seem more than deserving of a “high” risk assessment.
I blame excessive and unwarranted bad press for some of that, but that’s not the only place the blame lies. The Mozilla Foundation needs to stick it to Microsoft on the issues where the former has a real advantage. Firefox should be marketed as what it is: a browser that won’t force you to risk compromising your system to install simple browsing-enhancers and a browser that is backed by a team of developers who aren’t hobbled by bureaucracy or afraid to change code in the name of user security. Offering less is what Microsoft got away with for years (and what got them scorched in the media), and it’s exactly what most of the Firefox user base got away from.
Mozilla should ‘fess up to vulnerabilities in its code and practice the one thing where it consistently has Microsoft beat: fixing them. Meanwhile, an honest assessment of the severity of bugs would help sustain the support of users like me who see Firefox’s practical advantage in the security realm as one of its most important assets.