Knowing When To Run: Cutting Loose From The Little Blue E

So I committed a slight act of title thievery from Scott Granneman’s book (yes, that’s right, book) of reasons and methods to avoid Internet Explorer. The spyware plagues that strike IE are oft-cited by the crowd of Windows opponents (most of whom are zealots) as reasons to abandon IE and Windows altogether and why no sane person should ever use them. While I generally agree with their view, as far as abandoning IE is concerned, I fault the logic that takes them to that view as the reason why it isn’t better-understood.

The biggest reason I will never-again use Internet Explorer has nothing to do with the level of security of the product. As we’re seeing with the spate of reported vulnerabilities in Firefox, it’s not a cure-all, either, and might be just as susceptible to security problems as IE. However, it has an advantage that IE, treading its current path, will never capture.

Microsoft made Internet Explorer significantly tougher (though not impossible) to attack with Windows XP Service Pack 2, and promises to do so again with Windows Vista. However strong Microsoft’s technical investments are (and disregarding my loathing of bundling browser-related security into an OS update), they focus on half the battle and therefore will more-than-likely not produce a substantial change in the security climate for the browser.

If you look at the numbers of vulnerabilities, and weigh the risks associated with vulnerabilities in both Firefox and Internet Explorer (making this an artificial dilemma for a moment — there are other choices, I know), there isn’t much difference. The patterns change slightly, but the two products end up offering roughly equivalent security on an actual product vulnerability scale.

So why, then, would anyone be so adamant in choosing one product (or any product) over Internet Explorer? One word: risk. Microsoft has reduced the number of vulnerabilities in IE some by code review, and has reduced the damage potential and attack surface via various security additions, particularly with XP Service Pack 2. However, a vulnerability in Internet Explorer that is of identical severity to one in Firefox (or, really, almost any other browser) is a much greater risk in a practical sense.

The only reason this is true: the QA processes at Microsoft are drastically different from its competitors. Bruce Schneier’s blog post, nicely-titled “Internet Explorer Sucks”, led me to an interesting study of practical risk in several browsers in 2004. The studied variance was the number of days a browser had a known, un-fixed security hole. IE’s total? 98 percent. IE escaped having a known-unpatched vulnerability for a whole seven days in 2004. The percentages for its competitors are in the teens, with Firefox at 15% and Opera at 17%.

I’ve been saying it for quite some time now: incident response is the Achilles heel of Internet Explorer’s security record. I was beginning to think that perhaps my view of the situation was colored by personal knowledge of months-old security flaws in the product. Instead, this study shows that the perceived security problems in IE are very much real. One of two things is to blame for Internet Explorer’s lax security:

  1. Code that is so crappy vulnerabilities are constantly being uncovered
  2. Vulnerabilities that are publicly known take much longer to get patched

I don’t believe that the code in IE is significantly worse than what makes up most other browsers (not to say that’s always been my opinion, or that IE is any better than its competitors today), so I believe the second explanation is the likely cause of this outcome. Microsoft is losing its security battle because it doesn’t understand practical security. This battle has really been lost on two fronts.

  • TimelinessAll the secure design in the world doesn’t do you a bit of good if the one vulnerability that most of the world knows about remains unpatched for months-on-end. Microsoft has been particularly slow in getting out Internet Explorer fixes over the years, with this week’s Font Embedding Buffer Overrun Fix (160+ days-to-patch) being no exception.
  • ApproachMicrosoft’s “fix-it-if-it-owns-them” approach to handling security vulnerabilities has drawn a considerable amount of well-earned negative publicity. Users were irate that Microsoft passed up a chance to close the trivially-exploitable DOM race condition vulnerability, dismissing it as a mere crash for almost six months. What Microsoft doesn’t seem to understand is that a defect is a defect is a defect, and the mere existence of defects can create situations that are unnecessarily hazardous to the security of systems. One of them is not-at-all technical, and is purely linked to when investigators miss exploitable holes.

Too many people are faulting Microsoft’s assessment processes for the DOM screw-up, under the false assumption that it is (and will be) an isolated occurrence. The reality is that the reliance on an assessment process is what is screwed up. The “if it ain’t burning, fix it next year” approach that Microsoft is famous for is the only reason why the DOM bug was allowed to turn into an unpatched, exploitable hole. And it won’t be the only one. Microsoft’s maintenance releases are too sporadic and too large in deployment cost to be used as an effective vehicle for distributing fixes for security issues. Yet, the company continues to rely on this methodology for fixing issues it arbitrarily deems to be unworthy of a bulletin release. With more WMF issues surfacing this week, I hope they can get away with it this time.

Regardless, this “wait and see, hope and pray” approach, particularly in combination with an already dog-slow update process, contributes directly to the security problems that Microsoft’s products (and Internet Explorer in particular) are experiencing. It is that element of managed-insecurity that is unique to Microsoft, and that is the reason why Internet Explorer should be abandoned like the burning ship that it is.

  • Jim Voorhees

    Microsoft has institutional problems with fixes that good will, excellent design, and technical acuity cannot solve.

    Consider the recent wmf vulnerability. Microsoft put 200 people to work to find the fix. Once it was found, it had to be tested extensively. Once approved, the documentation for it had to be translated into more than 20 languages.

    Microsoft’s customers require all this. They have also preferred to have all fixes come on a predictable schedule.

    Given that all this is required, and that it takes time, Microsoft showed remarkable flexibility and speed. To ask them to react as quickly as Ilfan Guilfanov, who wrote and issued a patch in a matter of hours, would be to ask a supertanker to turn on a dime.

    This is neither simply to praise Microsoft nor to offer one more argument for abandoning IE. It is to outline a problem that affects all of us when the millions of users who rely on Microsoft get attacked.

  • Justin Perez

    The owner of a super tanker wouldn’t have millions and millions of dollars flowing in on a monthly basis, although I’m sure if it did, we could expect it to have the resources necessary to make it capable of turning on a dime.

  • Matthew Murphy

    I, for one, am not asking Microsoft to “turn on a dime”, except when that’s absolutely necessary (i.e., active exploitation and public announcements). However, 160-220 days for a patch is wholly unacceptable.

    Further, one of the biggest institutional problems MSFT has is that it seems to be scared of making changes to its own code.

  • Penedo

    I agree with the first post about Microsoft being a supertanker in that regard and having to meet much stricter requirements than a lone programmer who isn’t accountable to anyone except for his good reputation.

    But that’s sort of a point against using “the supertanker of the software world” when smaller, chaper, more agile and just generally better boats are available to cruise with.

  • Lev

    I, in opposite, tend to disagree with such a parallel, software industry is not a shipbuilding one (historical comparison). A tiny hole can not sink the tanker, but can big time f**k up Os and the business running critical tasks on it.