The Evil of Silent Patches: Microsoft’s Three-Year-Old Hole
When I was reading an iDefense advisory on a vulnerability in Trend Micro’s ServerProtect Console, there was a feeling that I just couldn’t shake. For some odd reason, the vulnerability felt oddly like deja vu. I kept thinking to myself:
I’ve seen this before.
While reading the “Vendor Response” section of the advisory, I realized exactly where that feeling came from. The chunked encoding issue iDefense reported was, in-fact an exploit vector for the Microsoft Foundation Classes (MFC) vulnerability I reported in July 2002.
As bad as Microsoft’s security processes still are, they were ten times worse back then. I’ll admit that. When I reported the vulnerability to Microsoft, a case on the issue wasn’t even opened. It wasn’t until I based public criticism of MSRC many months later on the still-unfixed vulnerability, that they re-opened the bug. Finally, Visual Studio 6.0 Service Pack 6 closed the issue in mid-2004. This timeline alone is not anywhere near defensible, particularly for an exploitable heap overflow. But if you think that’s bad… hold onto your chair.
When SP6 was about to be released, I was contacted by someone from MSRC and personally asked to announce the availability of the fix to the discussion lists where I had originally publicized the vulnerability. To this day, I still have not done that. The urge to become a wonderboy PR-piece for the world’s largest corporate empire, it turns out, is not that hard to resist.
The only reason I refused to do this, was because I expected word of the vulnerability fix to reach developers the same way news of other fixes did: from Microsoft. So, of course I was horrified to find that the Visual Studio Service Pack 6 release documentation made absolutely no mention of the vulnerability. Soon, the real reason why I was asked to deliver news of the fix became obvious: Microsoft was protecting its own hide rather than telling customers about the bug. The justification they offered me was even more damning: Microsoft couldn’t possibly hope to reach the developers of vulnerable code, so they shouldn’t place customers at risk by publicly announcing the security fix. It then followed, that because I, of course, would only announce the fix to the same fora where I announced the vulnerability, that the risk to customers could not be further increased as a result.
Does that make sense to anyone else? Didn’t think so… but I was just checking.
So, given the complete lack of any effort on Microsoft’s part to inform even its largest customers that they and their software were affected by a serious security hole, I can’t say I’m surprised by this week’s developments. Now, in December 2005, more than three years after this vulnerability was discovered (and reported publicly), a major manufacturer of security software has been found vulnerable to an attack vector that should have been dealt with better than a year ago… simply by compiling new binaries and distributing them to customers.
While this is an extreme example, it goes to show just how important information is in shaping response. Security fixes cannot simply be made and forgotten: they need effective distribution and uptake to have real-world impact. It wasn’t the lack of a fix, but poor distribution and uptake of a security patch that enabled Blaster to infect 25 million Windows PCs, and bring entire networks to their knees. And… what better way is there to cripple uptake rates than to simply not inform users of the availability of a fix?
We can only hope Microsoft has learned its lesson… if approaches like this remain the norm there, we’re going to be dealing with more viruses, more sleepless nights, and more pounding headaches for quite a while before they ever get it right.