Hi everyone, Mike Reavey here.
We’ve gotten some questions from customers about when we got the first report of this vulnerability and how long the investigation has taken relative to the outbreak of attacks against this vulnerability.
Before I go into the details, the key thing I want customers to understand is that this is an issue that was responsibly reported to us and we have been driving in our standard process towards a security update. While in the middle of that process, attackers found this same vulnerability and began attacks against it. We were far enough in the process that we could provide information that customers can use to protect themselves in the interim while we complete that investigation and deliver a security update that you can deploy broadly with confidence. Like Jerry said, we’re targeting next Tuesday to release this update.
In terms of timeline, we received the original report from Ryan Smith and Alex Wheeler with IBM ISS X-Force in the early Spring of 2008. The CVE number assigned to this, CVE-2008-0015, can make it look older but that’s because IBM (like Microsoft) gets CVE numbers in large blocks and assigned them sequentially to issues.
Once we got the report, we started an investigation and confirmed that this ActiveX control that ships with Windows did expose an exploitable vulnerability that could be exploited by malicious websites.
We always aim to be thorough in our investigations. For any issue that is reported to us, we strive to address not only the vulnerabilities brought to us but also to find any similar or related issues to ensure the update provides as comprehensive security as possible. And once we confirmed that issue we expanded our investigation to be thorough.
In the case of this particular issue, part of our investigation showed other interfaces were vulnerable, in this ActiveX Control, not only the one seen used in attacks.
Another thing our investigation showed is that there was no known use for these interfaces in Internet Explorer. In fact, as part of our security work on Vista, these interfaces had been disabled in Internet Explorer.
Based on that, our engineering teams felt the best approach to protect customers would be to prevent these any interfaces with no know use in Internet Explorer (45 in total), from loading in Internet Explorer in earlier versions of Windows.
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.
We were far enough along in our process that we felt comfortable taking this information from our investigation and giving it to customers so they could take immediate action to protect themselves while we finish our security update. To make it even easier for customers to protect themselves, we also implemented the “FixIt” that automatically implements the killbits.
Customers who have already implemented the killbits manually or through the FixIt workaround won’t need to implement next week’s security update, though we recommend that you apply the update to ensure that reporting accurately shows that the systems are fully protected.
We’re on track to release the security update next Tuesday. But if you haven’t implemented the killbits already, we recommend that you go ahead and do that to protect yourself against the attacks.
I hope this helps answer any questions you might have.
*This posting is provided “AS IS” with no warranties, and confers no rights*