When faced with suggestions from everyone from CERT to Slate to stop using IE, it certainly raises (or should raise) some questions in folks’ minds about whether that’s good advice….
When faced with suggestions from everyone from CERT to Slate to stop using IE, it certainly raises (or should raise) some questions in folks’ minds about whether that’s good advice. And the standard response (which I can say with some authority, as it was one of my responses) is: Why is Firefox/Mozilla any different? Any browser is going to have security holes here and there.
True. There are some architectural issues that come into play as well, but if every hacker with spare cycles on his/her hands put their mind toward attacking Firefox, they would find bits to exploit.
Society does a lot to keep fires from starting in cities. Building codes, safety programs, sprinkler systems, stuff like that. We’re better off for them, certainly, but accidents (and arsonists) still happen. In which case, what’s also key to dealing with fires is how you fight them when they come up.
Last week, a vulnerability was discovered in Mozilla/Firefox. It’s actually present in IE, too, and there are reasons why it happened, but it resulted in a lot of crowing from IE boosters about how, See, we told you that stuff is vulnerable, too.
So what did the Firefox/Mozilla folks do about it? This.
July 7 – 13:46 GMT – Keith McCanless files a bug in the Bugzilla Database reporting a new vulnerability. It exploits the windows “shell:” handler and allows a malicious web page to execute a program on a client’s computer (The program has to already be present on the computer). McCanless notes that the bug is “BOTH a security concern and a DOS,” since if the link points to a nonexistent file, it makes the Mozilla browser spawn off endless amounts of new windows. The bug is marked private since it is security-related; only developers with proper clearance can see it. […]
July 7 – 18:16 GMT – Mozilla developer “timeless” creates patch closing vulnerability. He posts the patch on the Bugzilla Database so that other developers can approve it. (source) The bug had been known to the world for a matter of hours before a patch was created to fix it […]
July 8 – 03:23 GMT – A new branch is created, out of which developers will build new versions of Firefox and Thunderbird. The patch is checked into this branch. In less than 11 hours after the vulnerability was reported to the public, all up-to-date Mozilla code was secure […]
July 8 – 16:13 GMT – Firefox XPI “add-on” package placed on FTP site. Once again, this fixes the bug without making users download a whole new setup file. Before the vulnerability was known to the public for 24 hours, Mozilla had released updated versions of its poducts and patches for users running previous versions […]
July 8 – 21:57 GMT – Asa Dotzler checks in an official Mozilla.org notice of the vulnerability and the fix. In the course of less than a day and a half of public vulnerability, all Mozilla versions were updated, a security note was released, and new downloaders were secure by default.
Now, nothing’s perfect, and in reality the issues surrounding this problem have been known and under discussion in the Mozilla world for some time. No actual exploit had been detailed, but nothing had yet been done.
The Mozilla developers did a great job handling this extremely critical security hole. After getting word of an exploitable hole, they pushed out a fix in less than 36 hours. Applause. The system worked.
…but not perfectly. The critical bug got fixed in a jiffy, but it was actually the result of known weaknesses in the way Mozilla handles external protocol handlers. These weaknesses came up many times on Bugzilla, starting around 2 years ago. The developers quelled some concerns by implementing an insecure protocol blacklist, but this solution did not fix everything. What I propose here would not have plugged this security hole entirely, but it would have mitigated it to a great deal. I can’t see how the Mozilla team could have prevented this problem entirely, but had they handled several known bugs, it could have been a minor issue.
The disadvantage you have with an open source project like Mozilla is that, in order to convince the developers to do something about it (assuming you don’t do it yourself), you need to convince them that it’s technically important. With Micro$oft, in order to convince it to do something, you have to show that it’s financially important (i.e., that they should mobilize the manpower necessary to make the change — which has more profound impact on M$ in this case because of the tight integration between IE and the OS. Hoisted on their own petard, they are …
Anyway, it was an impressive effort, and kudos to the folks at the Mozilla Foundation involved in this.
Definition of terms, as I understand it (and so that some of the above isn’t completely opaque):
Mozilla is an open source project spun off from Netscape, including a browser and an e-mail client, and a few different kitchen sinks, too. It’s at version 1.7 at this point.
A decision was made, after Mozilla went “live,” to break out the components into their own stand-alone products. The browser has become Phoenix Firebird Firefox , and is at version 0.9.2 (not yet “officially” released). The e-mail client has become Thunderbird (about which I know less, though I may soon know more).
So you can use “Mozilla” to refer both to Mozilla and Firefox and/or Thunderbird, or you can use the individual project names, or you can use lots of slashes between the names to be inclusive. I think I managed all of the above above.
(via BoingBoing)
