Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
Today, we’re releasing guidance and security updates to help better protect customers from responsibly reported security vulnerabilities discovered in the Microsoft Active Template Library (ATL).
Because libraries function as building blocks that can be used to build software, vulnerabilities in software libraries can be complex issues and benefit from what we call community based defense – broad collaboration and action from Microsoft, the security community and industry. Because of this, in addition to the updates and guidance we’re releasing today, we’ve been actively engaged with the industry through programs like the Microsoft Active Protections Program (MAPP), Microsoft Security Vulnerability Research (MSVR) and working with organizations such as Industry Consortium for the Advancement of Security on the Internet (ICASI) to provide a broad, industry-wide response to help better protect customers. While this is a complex issue, we believe a broad, industry-wide response can help minimize the impact to customers.
The vulnerability that we addressed with Microsoft Security Bulletin MS09-032 was a result of this issue. While that issue was attacked before a security update was released, that is the only known attack that we’re aware of against an issue related to vulnerabilities in the ATL. However, we are releasing our guidance and updates outside of our regular monthly release cycle because our updates are of appropriate quality for broad distribution, we are aware of one attack which was addressed through MS09-032, and we believe that there is a greater risk to customer safety from broader disclosure of this issue if we wait until our next scheduled release on August 11, 2009.
We have focused our efforts on this issue around two main fronts:
1. Helping developers to identify and address instances where the ATL vulnerability manifests in their controls or components
2. Mitigating the impact of future attacks on customers
Some of the steps that we’re taking to help developers include:
1. Releasing MS09-035 for Visual Studio which provides an updated copy of the ATL that developers can use to build new controls and components if needed. It is important to note that not all controls built using the vulnerable versions of the ATL are vulnerable – this will depend on decisions the developer made when building the control or component.
2. Posting a special developer resource page with detailed information on how developers can identify if their control or component is exploitable using the vulnerabilities in the ATL
3. Working with ICASI who is partnering with Verizon Business to offer customers a no-charge service that will scan developers’ controls and components and provide initial indications if the control or component is vulnerable and what potential next steps customers or developers should take to modify the control.
4. Working with vendors responsible for widely used controls and components through our Microsoft Security Vulnerability Research to help them identify and address instances where the ATL vulnerability manifests in their controls or components.
5. Reiterating our commitment to third party developers to set “killbits” for their ActiveX controls on request in a Microsoft Update.
Some of the steps we’re taking to mitigate the impact of future attacks on customers include:
1. Releasing MS09-034 for Internet Explorer. While Internet Explorer is not itself vulnerable to the ATL issue, the IE team has built a defense-in-depth change that can help protect against attempts to attack controls or components containing the ATL vulnerabilities. More detailed information on how this works is provided at the Security Research and Defense blog. This update also addresses an issue where attackers can attempt to bypass the “killbit” protections in IE. Finally, this update also addresses three unrelated, responsibly disclosed vulnerabilities.
2. Providing information to our MAPP partners to help ensure security protection providers have key technical information to help them build protections for customers more quickly.
3. Committing to set “killbits” in a Microsoft Update for vulnerable third-party ActiveX controls identified as vulnerable or under attack when no vendor can be identified.
Home Users and IT Pros should go ahead deploy the IE update, MS09-034 so they can benefit from the protections it introduces. Additionally, Internet Explorer 8 provides additional security enhancements that can further lessen the impact of this issue. There’s more details on that at the IE blog. Also, enabling automatic updates for third-party software (where available) may help you get the latest updates for those products.
Developers should take the same steps as home users and IT Pros but should also review the information we’ve provided to help you determine if the ATL vulnerability manifests in your component or control. Additionally, you should consider using the service offered by ICASI who is partnering with Verizon Business to identify any components or controls that are vulnerable.
Because we know folks will have additional questions, we’ve posted additional information on our security blogs. Our colleagues at the Security Research and Defense blog have several posts related to this that Jonathan Ness points to in his overview post. Michael Howard over at the SDL blog has one going into some more detail around the actual underlying issue. Katie Moussouris and Adrian Stone talk about MSVR’s work with other vendors on this issue over at the Ecostrat blog. And, finally, Ryan Smith, Mark Dowd and David Dewey, the security researchers who brought this issue to us, discuss their work on the issue with us over at the BlueHat blog.
Our worldwide security teams have been mobilized working around the clock to deliver these protections to customers and we will be continuing to watch the threat landscape closely. We will work closely with our partners in the industry and notify customers with any new information about this situation through our security advisory and the MSRC weblog.
*This posting is provided "AS IS" with no warranties, and confers no rights.*