On the Soapbox

On December 20, 2006, a security company named Determina privately reported to Microsoft a vulnerability in how Windows handles animated cursors. According to Microsoft, they immediately began to "investigate" the issue in December. Not much was heard about this bug until last Wednesday when McAfee reported to Microsoft about a new attack using a previously unknown method. Microsoft then launched their incident response process and issued a security advisory the next day.

On the surface, a bug in how Windows handles animated cursors does not seem to be a very serious problem. (Edit: The following passage has been updated.) However, it is possible in CSS to specify different mouse cursors--for example, if the site owner wishes for the mouse to remain an arrow instead of turning into a hand when hovering over a link. It is thus possible to embed animated cursors on a web page or in an e-mail. Because mouse cursors are rendered by the operating system and not by the browser (the browser effectively tells the operating system to change the cursor), this is an operating system bug that affects all browsers that support the changing of mouse cursors through CSS (which is a part of the official CSS specification). What this means is that if you just visit an infected website, you will be immediately infected without the need for you to do or click anything. Or, if you open, read, or even preview an infected e-mail, you will be immediately infected even if you don't open any attachments in the e-mail. In other words, malware that exploit this vulnerability are extremely virulent. Infected websites could either be created by hackers, or they could be legitimate websites that have been discreetly compromised and hacked to deliver a payload without the website owner's knowledge (which meant that Microsoft's recommended temporary solution to "not visit untrusted websites" is not very practical because it is possible for any "good", but poorly-secured, website to become unwitting infection vectors). Once infected, anything is possible, depending on the payload delivered by the virus--including the possibility of a complete takeover of one's computer and the compromise of all data on it.

The severity of the problem grew significantly worse on Friday and over the weekend, a spam campaign was launched with e-mails that either contained a malicious payload or that had links to websites that delivered a malicious payload. Later in the weekend, a tool was made public that allowed anyone to attach any payload of their choosing to an infection vehicle that exploited this vulnerability. In response, various security groups raised their "alert level", including SANS, which hadn't raised its alert level in almost a year. Recognizing the severity of the problem, Microsoft announced on Sunday that they have a fix and that they will be releasing it on Tuesday. Microsoft always releases their security updates at the same time, on the second Tuesday of each month (known as "Patch Tuesday"), and it is only in rare and severe circumstances, like this one, that Microsoft will deviate from the schedule and release a security update early and separately from the rest.

What is most interesting about this story is how Microsoft responded. This incident never would have happened and goodness-knows-how-many computers would never have been compromised (it will be impossible to measure how many computers were infected because of the large number and wide diversity of different payloads that exploited this vulnerability, though it should be safe to assume that the number will likely be very high) if Microsoft had just fixed the problem in December instead of just "investigating" it for over a quarter of a year. Microsoft clearly didn't think very much about this problem until it was too late. Like most other vulnerabilities, this one uses a buffer overflow, and these are generally very easy to fix. In fact, on Friday, mnin.org was able to locate the exact location of this particular bug, and eEye had created an unofficial "quick-and-dirty" fix for the problem on Thursday. On the other hand, Microsoft, with their vast resources and intimate knowledge of their own code, took more than three months to "investigate" the problem. I suppose this is one of the things that makes Mozilla software more secure. Firefox is not devoid of security vulnerabilities--there has been so many that I've lost count (though still not as many severe ones as Internet Explorer), but after observing how they have handled their security vulnerabilities, it becomes clear that they take an approach that might be described as being excessively paranoid. Each vulnerability, no matter how obscure, is treated with great urgency, and most security flaws are patched within a few days of their initial reporting, even if no attacks exploiting the vulnerability exist and even if the vulnerability has never been publicly disclosed. This is in contrast of Microsoft's practice of quietly sitting on known security vulnerabilities as long as no attacks that exploit them exist and as long as a particular vulnerability has not yet been publicly disclosed, in the gamble that perhaps nothing will ever come of it. Well, this time, Microsoft lost the gamble in a very grand way, and average computer users are paying for it with hijacked systems and compromised data. (Edit: Unfortunately, in this case, because the bug is a OS-level bug, it will affect all browsers, even those not made by Microsoft, but it does serve to illustrate a different approach to such bugs that Microsoft takes.)

Update: Interestingly, a similar vulnerability was reported and fixed in 2005. See Determina's notes.