Next Week's Firefox 3.0.8 Release Termed "High-Priority Firedrill"

by Ostatic Staff - Mar. 26, 2009

There are many reasons to love the open source approach. The events chronicled in an article on NetworkWorld surrounding an exploit affecting Firefox outlines, quite elegantly, how open code outwardly appears risky, and -- well, wide open -- and how that same quality generates faster fixes and stronger applications.

A security researcher discovered that Firefox is vulnerable to remote memory corruption, enabling attackers to execute malicious (or at least very much unauthorized) code within the context of the browser. While security researchers spend countless hours searching out bugs and vulnerabilities, it's not usually the case that the offending attack finds its way into the public eye. Yesterday, however, this little exploit was published on several security sites. The vulnerability affects Firefox versions 3.0 through 3.0.7, on all platforms. In less than 24 hours, developers issued a patch for the vulnerability, to be included in next week's 3.0.8 release.

Put aside, for a moment, the quick turn around time on the patch, and take a look at the comments on the bug report. The person filing the bug states that while the attack code calls an empty, harmless XML file (with an XSLT transform) now, the fact that it's being called at all is a real cause for concern. The developer leading the fix, Blake Kaplan, takes a look at the problem on several platforms and versions, begins patching them, and says quite candidly that the bug is obvious "once you see it." This is why the open source approach works well -- this is a real life example of the "many eyes" mythos. These developers work with this code all day, but it doesn't mean it's easy (or possible) to see every way it could be vulnerable.

No application is perfect, and bugs and vulnerabilities happen. The lasting effects on a project often have less to do with the damage done so much as how well damage control was carried out. A quick fix is great, but a developer team that acknowledges issues and talks about them publicly suggests the project isn't merely the source of a paycheck or place to spend spare hours -- it is a responsibility taken very, very seriously.