|09 Jul 2009||#1|
Questions about Timing and Microsoft Security Advisory
Hi everyone, Mike Reavey here.
You’ve probably seen in Jerry’s Advance Notification posting today announcing that we’re on track to release an update to address the issue discussed in Microsoft Security Advisory 972890.
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*
|My System Specs|
|Similar help and support threads|
Microsoft Security Advisory (2490606)
Microsoft Security Advisory (2490606): Vulnerability in Graphics Rendering Engine Could Allow Remote Code Execution Microsoft releases Security Advisory 2490606 - MSRC - Site Home - TechNet Blogs
|Windows Updates & Activation|
Microsoft Security Advisory (2286198)
Microsoft has released Security Advisory 2286198, which addresses a publicly reported vulnerability in Windows Shell. From the Security Advisory: If AutoPlay is disabled, particularly for USB devices, in order for the vulnerability to be exploited, it would be necessary to manually browse to the...
Microsoft Security Advisory (980088)
Microsoft Security Advisory (980088) Vulnerability in Internet Explorer Could Allow Information Disclosure Published: February 03, 2010 Version: 1.0 Microsoft is investigating a publicly reported vulnerability in Internet Explorer for customers running Windows XP or who have disabled Internet...
Microsoft Security Advisory (979352)
Microsoft Security Advisory (979352) Vulnerability in Internet Explorer Could Allow Remote Code Execution Published: January 14, 2010 General Information Executive Summary Microsoft is investigating a report of a publicly exploited vulnerability in Internet Explorer. This advisory contains...
Microsoft Security Advisory 973882, Microsoft Security
© Designer Media Ltd
All times are GMT -5. The time now is 14:07.