Microsoft has expended a massive amount of time, energy and money in the last few years to improve both the quality of its software and the speed and efficiency of its security response process. It has succeeded in large part on both counts, especially on the security and reliability of its products. But, as the company’s response to the privately disclosed MsVidCtl ActiveX vulnerability in Internet Explorer shows, Microsoft still has some ground to cover on the issue of timely response.
The time line on how long Microsoft has known about the vulnerability in MsVidCtl, a DLL in the DirectShow video control in Internet Explorer, is a little fuzzy, but the company itself acknowledges that Ryan Smith and Alex Wheeler of IBM ISS reported the problem in “early spring 2008.” Microsoft started its normal security response process, which involves trying to replicate the problem, determining which applications and versions are affected and figuring out the best method for correcting the problem. How long this process takes can vary greatly, depending on the application involved, where the vulnerability is and a number of other factors.
But Microsoft has turned patches around in as little as a few weeks in cases where there were critical flaws that were under attack in the wild. When Microsoft first got wind of the vulnerability last year, there were no indications that the flaw was being exploited. So the response process progressed at a normal pace. But the process dragged on and on to the point that when reports surfaced last week that the MsVidCtl vulnerability was being used in a mass exploitation attack, Microsoft still not have a fix ready. Even if we put the report to Microsoft sometime in April 2008, that’s 15 months between the notification and Microsoft’s release of the patch today.
Microsoft’s Mike Reavey said in a blog post on the issue that the company’s engineers discovered that the vulnerable interface in the ActiveX control had no real use in IE and that the best way to fix the problem would be to prevent that interface, as well as several other unneeded ones, from loading in IE.
“However, disabling or removing functionality is a more radical step than updating code to address an unchecked buffer, for example. When we disable or remove functionality, we have to engage in even more research and testing than usual, to ensure that we can take this step and not cause more harm than good by inadvertently “breaking” applications. For something like this, we have to ensure not only our applications but also major third-party applications are not hurt by this. Otherwise, if our update “breaks” a major application, customers won’t deploy the update but the bad guys will have information about the vulnerability that they can use to attack it,” Reavey said.
The concern about breaking other Microsoft or third-party applications is a legitimate one, but it’s something that Microsoft and every other software vendor has to deal with any time they release a patch. This is nothing new; it’s a given. The quality and compatibility testing process can take some time, but 15 months is just too long. That’s nearly a year and a half that millions of customers were left exposed to a critical flaw that attackers now are using to compromise large numbers of PCs.
And just because the first reports of attacks on this exploit only came to light last week doesn’t mean that attackers haven’t been using it for much longer than that. Multiple independent discoveries of vulnerabilities is a common occurrence, and attackers may well have been using the MsVidCtl flaw in targeted attacks long before it became the fuel for the mass exploitations.
In related news, Microsoft on Tuesday also released a patch for a somewhat similar flaw in DirectShow that was reported in May, a turnaround of less than two months. That’s a much more reasonable time frame and is more in line with what Microsoft is usually able to do. Let’s hope that the MsVidCtl response was an aberration and not a return to the indefinite waits customers once endured for patches for Microsoft vulnerabilities.
