Hey Folks – this is Mike Reavey.  We’re all glad that MS07-017 – the Security Bulletin that fixes the vulnerability in Animated Cursor Handling (CVE-2007-1215) – has been released, helping to block attacks on that vulnerability.  While we released it within 5 days of being notified of attacks, we have received questions from customers about why it took us 3 months to develop and release the fix for this vulnerability.  I wanted to provide some insight into the history of this vulnerability, and while doing so, hopefully provide insight into the overall security update lifecycle, including testing, which consumes the greatest amount of time.

History of the Vulnerability

As we’ve mentioned, this vulnerability was responsibly reported (which means confidentially reported) to us by Determina on the 20th of December.  When the report came in, we immediately understood the severity of the issue and triaged this as a vulnerability that would require a security update. 

This issue followed the same process that we use for all vulnerability reports. Based on the severity of the initial report, we began driving for release right after we were able to verify the vulnerability reproduced.  The level of priority that we assign to a vulnerability is based on the severity of the vulnerability and the risk to customers.  The level of urgency and our willingness to “shortcut” steps in the process, such as quality testing, to release on a faster timeline is based on the actual risk to customers at that time.  Regardless of whether or not an issue is responsibly reported, if customer risk is imminent we will balance the need for quality and comprehensiveness (investigating, fixing and testing any vulnerabilities in related code) with the need to protect customers as quickly as possible.

Building the update

The first stage in our investigation process is the triaging stage. As part of that, we not only investigate the specific issue that was reported to us, but any surrounding issues. Customers have told us clearly that they want us to make the security update as comprehensive as possible, they don’t want to have to apply multiple updates to address issues in the same components. So our triaging stage focuses on finding as many related issues as possible.

In this particular case, our investigation through January and February showed that there was a dependency between one of the files required to address a related vulnerability in a system driver that runs in kernel mode (win32k.sys) CVE-2006-5758 and the file that needed to be updated to resolve Windows Animated Cursor Handling vulnerability CVE-2007-0038 (user32.dll).  That dependency meant a comprehensive update needed both files to be applied to systems at the same time, and our investigation included multiple components. 

The result of this comprehensive investigation was that in MS07-017 you’ll see we fixed 7 reported vulnerabilities as well as other issues found through internal investigation, instead of asking customers to deploy multiple fixes for the same set of vulnerabilities. 

Testing the update

The next stage in our investigation process is creating and testing the security updates which this update went through in February and March. This is an extensive process that takes, on average, two months for the majority of Windows related security updates. 

For this issue in particular, the update modifies functionality that is pervasive and core to the operating system, both in graphics rendering, as well kernel mode operations.  So extensive testing was performed, and that process involved hundreds of folks in multiple teams worldwide to ensure as complete coverage as possible.  In this case at one point our testing had uncovered over 80 potential issues with the update that were investigated and resolved.

The result of our comprehensive testing is that at the time of release, only one minor quality issue was known and guidance as well as a hotfix was ready for customers at the same time of release.

Responding to the attacks

As we noted on Sunday, our target date for completing this process and having an update ready for distribution was April 10, 2007 as part of the April release. Last week, when the initial attacks were reported, we kicked of our company-wide SSIRP process.  As we were nearly complete with the testing cycle for the comprehensive update, we determined that we could best protect customers more quickly by expediting the testing on the comprehensive update rather than trying to develop a new update to address this issue by itself.

While I would hope it would go without saying, I personally want to make sure our customers know that the MSRC, everyone on my team and our extended teams takes each report seriously. 

Every vulnerability reported to Microsoft is triaged personally by a member of my team (in this case it was Adrian Stone as you might have realized from some of the prior blog postings) and they work on those issues reported to us end-to-end until the point we are able to produce an update that helps protect customers.  In many cases, there is a delicate balance we strive to strike between meeting customer needs, our ability to test an update for appropriate quality and protecting customers against possible attacks.  Of course we’ll always look for ways to improve our response time to help protect customers more quickly, without sacrificing quality in the process. 

I hope this gives some more detail and helps answer any questions you might have.

Thanks

Mike

*This posting is provided "AS IS" with no warranties, and confers no rights.*