Mozilla vulnerability timeline

Via my inbox, I found a very interesting blog post that outlines the timeline for fixing the recent shell: vulnerability in Mozilla. I tip my hat to the Mozilla team for their speedy response.. except that they forgot a couple of important things.


First of all, where was the testing? In the timeline, I don’t see any mention of any kind of testing to see whether their fix had any impact on legitimate uses of shell:. That implies that either a) they didn’t test it, b) they did test it but forgot to mention it in the timeline (unlikely, given how complete it is otherwise), or c) there aren’t any legitimate usages of shell: (in which case one might wonder why they implemented it.)
Next, what about code review? I notice that there was a (wait for it) three minute review listed in the timeline. I guess for a trivial change this might suffice. Then again it might not. Many eyes might make all bugs shallow, but in this case only one set of eyes spent 180 seconds reviewing the fix before approving it.
Third, if you have a look at this bug, you’ll notice in comment #11 that this was flagged as security critical in October 2002. However, it wasn’t fixed until July 2004. Oops.
Fourth, the original bug was tagged as “won’t fix”. Why? The dev team thought it was a Windows-only problem. Maybe it was, but oddly IE didn’t suffer from it– that sure makes it seem more like a Mozilla bug to me.
Fifth, I would point out that just because the team released a patch quickly, there’s no guarantee (heck, there’s no data) on whether users actually got that patch or not. Complain all you want about IE, but at least Microsoft has a robust system for notifying people of updates and, optionally, pushing them to affected machines.

1 Comment

Filed under General Stuff

One response to “Mozilla vulnerability timeline

  1. Why Mozilla? Why Not?

    Via Exchange Security: Mozilla Vulnerability Timeline. Impressive. Paul (Robichaux, who publishes the Exchange Security blog) criticizes Mozilla on a few things, such as not having “a robust system for notifying people of updates and, optionally, pushi…