Network News

X My Profile
View More Activity

Critical Microsoft & Mozilla Patches for 2006

A couple of weeks ago, Security Fix published some data showing how risky it was for the average Windows user to browse the Web with Microsoft's Internet Explorer in 2006.

That analysis found that for 284 days in 2006, bad guys were either exploiting critical, unpatched security holes in IE or blueprints for said instructions were published online for any criminals to use. In contrast, the data showed that there just nine days in 2006 in which exploit code was available for similarly serious, unpatched security holes in Mozilla's Firefox browser.

A great number of people who commented on that story and sent e-mail about it have been asking to see the raw data that I used to compile that information. So, here it is:

Microsoft's 2006 Critical Patches

Mozilla's 2006 Critical Patches

When reviewing this data, it's important to keep in mind that I only looked at the patches that were labeled "critical" by Microsoft or Mozilla themselves. Also, I don't think it's particularly useful to compare all of Microsoft's critical vulnerabilities to every critical Mozilla patch and draw conclusions about browser safety, which is why my earlier analysis only compared the patch and vulnerability times for Internet Explorer and Firefox flaws for which there was exploit code available before a patch was shipped to fix the problem.

Overall, I found that it took an average of about 113 days for Microsoft to issue critical updates in 2006. If you just look at all critical IE flaws that Microsoft patched in 2006 (not just the bolded ones, which indicate either the availability of pre-patch exploit code or evidence of active, pre-patch exploitation), Microsoft took about 90 days to push out an update. However, when it came to the most serious IE flaws (the ones in bold), Microsoft shipped a fix in about 40 days.

This post wasn't meant to stir up the virtual hornet's nest that is the eternal IE vs. Firefox security and usability debate. I merely wanted to publish the data sets (which took a great deal of time to compile) because they could be useful for other researchers (plus, I already promised I'd publish them).

I roll with Firefox for most of my browsing needs, but still rely on IE7 for a handful of trusted sites. Surf with whatever browser makes you happy. But please, if you're still using IE6 and haven't upgraded to IE7 yet, stop fiddling around. If you're using an older version of Windows (IE7 doesn't work on anything older than XP), I would run -- not walk -- away from IE in favor of just about any other browser.

One final note: I have tried very hard to be as accurate as possible with these tables. But if you find a discrepancy or something that doesn't seem to add up, please leave a comment below or drop me a line. If I can verify an error or discrepancy in the data, I will fix it and note that I have done so.

By Brian Krebs  |  January 19, 2007; 2:21 PM ET
Categories:  From the Bunker , New Patches , Safety Tips  
Save & Share:  Send E-mail   Facebook   Twitter   Digg   Yahoo Buzz   Del.icio.us   StumbleUpon   Technorati   Google Buzz   Previous: Great Strides in Phishing
Next: Sun Releases Java Security Update

Comments

One interesting aspect not mentioned but perhaps worthy of mention is directly related to availability of source via Mozilla Foundations CVS repository.

One needn't wait for Mozilla to release a bug fix. Once a bug fix is tested and accepted, it becomes immediately available in CVS.

Yes, I realize most users wouldn't be in a position to do this. That said, there are groups of users who actually have the ability to get these updates on a more or less immediate basis.

In particular, Gentoo Linux users {a source based distribution} regularly received accepted FF bug fixes within days of them being posted in Mozilla's CVS.

It wouldn't be a far stretch for a group like the people at Neowin to perform exactly the same service for Window's users too. i.e. Neowin already supports monthly releases of AutoPatcher.

For the security conscious, such a service would benefit many users who are not in a position to compile their own updated versions of FF.

As a long time Gentoo Linux user, we get nearly all FF security fixes within a day or two of them being posted to CVS. I'd be curious to know the number of days between a when bug was reported and the corresponding fix was posted to CVS.

Posted by: No Tellin | January 19, 2007 4:10 PM | Report abuse

BTW - I went back and read a few of the comments on your previous article. The unsupported assertions were quite amusing. I spluttered into my coffee when I got to the "... FF has HUGE memory leaks ...". Fortunately, my keyboard was out of range. :-D

The first thing I ask anyone who tells me they're having problems with FF consuming resources is which and what version Java Virtual Machine is loaded. Anyone who still has MS's VM loaded deserves to lose their memory, CPU cycles and peace of mind.

"HUGE memory leaks"? -heh- First, one has to figure out what's actually running. Not an easy task in the Windows environment with all it's resource calls piled on resource calls piled on resource calls. Second, one then has to prove that all of the other resource users are _not_ leaking memory. Now, in any version of Windows, that's something I'd pay good money to see!

As an aside, I run WinXP SP2 with the latest updates at work. I managed to reliably get my work PC to instantly reboot itself simply by trying to print a PDF document using FoxIt. Heck, I'd rather have a Blue Screen of Death!

Posted by: No Tellin | January 19, 2007 4:38 PM | Report abuse

No Tellin,

I've always been intrigued with this open-source approach to software and bug zapping in particular. My concern is that while it may be quicker to fix problems, it may also be less secure in that someone could *intentionally* embed a problem into a complicated patch. Assuming the patch actually works, it could be incorporated into the product, leaving a new intentional security hole for some future attack.

Being more familiar with the process, do you think this is a plausible scenario? What safeguards have to be done (and by whom) to double check patches before incorporating them into releases?

Posted by: Michael | January 22, 2007 12:33 PM | Report abuse

Michael,

Virtually all projects allow public read only access to their CVS trees. This means you and I and anyone else can download and view and play with the code to our heart's content.

By the same token, virtually all projects tightly restrict access to posting of changes to their CVS trees. Such posting also include MD5 / SHA1 / SHA256 security keys to verify from who the posting was made. Also, downloads from CVS also include such security keys so that anyone and everyone can verify the source of the download.

All large projects have a many eyes approach to accepting patches into their CVS trees. Part of this is to specifically look for any 'backdoors' a malicious contributor is attempting to slip in. i.e. No contributed patch is allowed without scrutiny by a bonafide official member of that project. This makes it extremely difficult for 'bad guys' to slip in any malicious code.

In Gentoo, there is a very complete security infrastructure in place to ensure that intentionally corrupted programs never make it to users. Every package downloaded has its integrity verified by no less than 3 security keys. These keys can only be obtained by Gentoo monitored mirrors.

In the Gentoo world, not only do the package originators maintain the security of their respective packages, but the Gentoo organization extends that security directly to the user's desktop. The same thing is true of the BSDs and nearly all of the larger Linux Distros.

From my observation, it's virtually impossible for such a scenario as you describe to occur. Historically, the only very limited significant attempts at such insertion have only 'worked' by hacking directly into a project's CVS server. This is very different from trying to 'slip in a backdoor' through the patch process. These failed through the simple expediency of turning back to the last available known clean backup and re-applying patches from that point.

Believe me, I sleep very securely at night when it comes to all of my PCs on my home network. :-D

I can't say the same thing about proprietary packages. By my personal count, I've seen articles at least four different occasions where a third party manufacturer was shipping CDs, including for Microsoft, which included malware.

Posted by: No Tellin | January 22, 2007 1:17 PM | Report abuse

Taking a simple average of the number of days to issue a security patch is perhaps the wrong way to do this analysis. Shouldn't there be a weight assigned to a security flaw? For example, taking a long time to patch a relatively minor flaw isn't as important as for a flaw that is serious and widespread.

I'm not a particular fan of Microsoft, but don't you think some of these security flaws for IE are fairly obscure and relatively unimportant? If they take a while to be fixed, so what.

Posted by: K.P. | January 23, 2007 10:50 AM | Report abuse

I couldn't help but notice that a lot of the purported IE patches weren't for IE - They were for some other application. Some were for Media Player and two were for Flash, which isn't even a MS product. If you're going to compare IE with FireFox then please, compare IE with FireFox. Seems like you're playing with loaded dice here.

Posted by: DT | January 23, 2007 11:09 AM | Report abuse

K.P -- As noted in the beginning of this post -- all the vulnerabilities included in this analysis were by Microsoft's own definition the most serious vulnerabilities they addressed last year -- they all received "critical" ratings, meaning they could be exploited to subvert the security of a Windows machine remotely with little or no action on the part of the victim. Moreover, as I said the real important analsys was already done weeks ago, on the unpatched critical IE flaws for which exploit code was available before a patch was out.

DT-- You'd have to be more specific about what your concern is exactly, and I'd encourage you go back and read the entire post. Again, this data sheet was merely a listing of all critical updates Microsoft issued in 2006. There are non-IE related critical vulnerabilities listed there, that's true: this data set was merely what I drew upon to conduct the IE vs. Firefox analysis.

Now, a couple of the flaws I counted as IE flaws you are correct -- were not specifically flaws in IE itself, but were nevertheless almost exclusively exploited or trivially exploited through IE. Take, for example, the very first flaw of the year -- in WMF files. That wasn't a flaw with IE, but nearly everyone whose machine got attacked using this vulnerability was attacked via IE. Same goes with the VML exploit and the MHTML parsing vulnerability.

Posted by: Bk | January 23, 2007 11:57 AM | Report abuse

just wanted to say hi to all seen some names from the past and took a mental walk down memory lane.

Posted by: Melissa | February 1, 2007 5:30 AM | Report abuse

The comments to this entry are closed.

 
 
RSS Feed
Subscribe to The Post

© 2010 The Washington Post Company