Last week Microsoft released MS08-055, patching a remote code execution vulnerability affecting the handling of onenote:// URLs in different versions of Office. What was surprising about the patch is that the vulnerability being fixed only bore a passing resemblance to the one that was notified to Microsoft in March of this year.
According to the Security Vulnerability Research & Defense team at Microsoft, the initial vulnerability was an Information Disclosure problem whereby it was possible to expose OneNote notebook contents via the onenote:// protocol handler. As the MSRC team began to build a patch to address the reported vulnerability, their due diligence turned up a more serious problem.
It turned out that the system library used to process parameters passed via a onenote:// URI was handled by the mso.dll and that there was a buffer overrun hiding in the DLL that could be triggered by parameters passed in a OneNote URI.
As mso.dll is used across many different versions of Office and some developer tools that use the functionality it meant that the patch needed to address a larger number of systems and products than originally planned.
The resultant patch provided a fix for the initially reported Information Disclosure vulnerability, patching only OneNote 2007, and the Critical update to versions 10, 11, and 12 of Office (Office XP, 2003, and the 2007 Office System).
Microsoft could have just patched the originally reported vulnerability and left it there (i.e. only the first part of the eventual patch). No one would have been any the wiser and the buffer overrun would have quietly remained in place, potentially to be targeted through another, later, vulnerability. It is possible that the Information Disclosure patch would have also patched the exploit vector for the buffer overrun, but the extra effort taken immediately following the initial bug report has resulted in a much more secure system for all Office users.
Could Microsoft have patched the initial vulnerability in March and then patched the buffer overrun in September? Sure, but patch delivery and priority is an internal decision by Microsoft. It would have been embarrassing to have another onload()-type nightmare, where a previously patched minor vulnerability (Denial of Service - May 2005) became a Critical vulnerability (remote code execution - November 2005) following increased attention by independent researchers.
If you're responsible for developing or managing patches and bugfixes for your company's software, can you say that you are conducting all necessary due diligence? There will always be pressure to hurry patches out and to downplay the severity of what has been found and it is unlikely that your products receive the sort of attention that Microsoft's do from hackers and researchers alike.
If you pride yourself on the quality of your work, how would you handle an onload()-type problem, where a previously patched issue turns out to be far more serious than initially assessed, and also not truly patched?
Effective security is a balancing act. Microsoft's recent example might be what you need to argue for greater time spent investigating reported issues and less time issuing hurried patches.