Hello everyone,
This is Christopher Budd. We’ve gotten some questions from customers around the security advisory that we released yesterday, Microsoft Security Advisory (935423). Specifically, we’ve been getting questions about:
· When we learned about the vulnerability
· When we learned about the attack
· What we’re doing to help protect customers
· When we expect to release an update
· Our recommendation around 3rd party workarounds or updates
I wanted to take a few minutes to answer these questions and give you the latest information on the situation.
When we learned about the vulnerability
We were first made aware of the vulnerability in Windows Animated Cursor Handling on December 20, 2006 when it was responsibly reported to us by a security researcher at Determina. My colleague Adrian Stone took the report and immediately began an investigation, working with Determina on the issue. We have been working on this investigation since December to fully understand the issue and have been working to develop a comprehensive update as part of our standard MSRC process. Determina has been and continues to work with us responsibly on this issue, and we thank them for helping us to protect customers.
When we learned about the attack
We first learned about the attack when were notified on Wednesday March 28, 2007 afternoon by McAfee through our Microsoft Security Response Alliance (MSRA) program. McAfee contacted us about a new, limited attack using an unknown method. We immediately initiated our Software Security Incident Response Process (SSIRP) to investigate the issue. Our investigation determined that the attack was utilizing this particular vulnerability. Our security teams worked overnight, and we released Microsoft Security Advisory (935423) on the morning of March 29, 2007 with information about the situation and steps that customers can take to protect themselves.
It is important to note that this issue wasn’t publicly disclosed by Determina. Sometimes issues that are reported to us responsibly by a security researcher are later found independently by other researchers who choose not to handle that issue responsibly and that is the case here.
What we’re doing to help protect customers
When we initiate our SSIRP process for an issue like this, our teams work constantly until the issue is resolved and customers are protected. We published the security advisory as part of that process, but that’s not all we do, and we don’t stop once we publish the advisory. As part of our SSIRP process we have multiple teams focused on ongoing work that can help better protect customers while we are working on a security update and we’re using them fully in this incident.
Our teams that focus on working with our partners through the MSRA have provided information to these partners through the MSRA that they can use to build signatures for products such as antivirus and intrusion detection and protection systems. These signatures can detect and protect against attempts to exploit the specific vulnerability. We also work with these partners to constantly monitor the threat environment for any changes which helps us with our ongoing assessment of the situation. We’ve also worked with partners and law enforcement to remove malicious sites that are attempting to exploit this vulnerability when our investigations have uncovered them.
We also have people like Jonathan on our security teams who continuously investigate the technical issues to better understand them and come up with more and better ways customers can protect themselves. As we have new information from our ongoing monitoring, research, and communications with partners, we update the security advisory with that information. So for example, we made an update last night to the advisory after our ongoing research found that “read as plain text” wasn’t a comprehensive protection for Outlook Express and would not always protect Windows Mail when forwarding or replying to the attackers’ email. We also updated the advisory to show that while the attacks are still limited, they were no longer targeted based on information from our ongoing monitoring.
When an update will be released
Our teams are actively working on a security update for this issue and we currently plan to release it as part of our regular monthly update process. That said, we are actively monitoring this situation as part of our process and will always consider releasing an out of cycle update if we have a quality update available and customers are at serious risk: we have done this before and can do it here if appropriate. However, we always try to release updates as part of our regular monthly release cycle because customers have told us that it’s easier for them to test and deploy updates when they’re released as part of a predictable process.
3rd party workarounds or updates
While we appreciate that these are provided to help protect customers, we do recommend that customers only apply security updates and mitigations provided by the original software vendor. This is because as the maker of the software, we can give our security updates and guidance thorough testing and evaluation for quality and application compatibility purposes. We’re not able to provide similar testing for independent third party security updates or mitigations.
I hope this helps answer questions people have about the situation and what we’re doing. We will continue to monitor and investigate this situation and make new information available through the MSRC weblog and our security advisory as we have it.
Thanks.
Christopher
*This posting is provided “AS IS” with no warranties, and confers no rights.*