Cat5bird Seat

Would You Install a Windows Patch From This Man?

Security fixes you obtain from the official source or a third party should still undergo the same scrutiny as any software you'd roll out to the troops.

• By Mike Gunderloy
• 04/01/2006

Back in January, you may recall, we had a bit of a fuss over a vulnerability in Windows. Microsoft referred to it as "Vulnerability in Graphics Rendering Engine Could Allow Remote Code Execution" but most everyone else just called it "the WMF hole." Whatever name you choose, this was pretty close a doomsday scenario. Just by browsing to a Web page containing a malicious image file, and doing nothing else (not even clicking on OK), you could get your computer taken over by The Bad Guys.

To their credit, Microsoft recognized the severity of this problem and pushed out a patch in record time, issuing it on a Thursday ahead of the usual Patch Tuesday. At that point, most Windows users with a clue deployed the patch via Windows Update, Windows Software Update Services, or some third-party patch management solution, and the forces of evil were thwarted for another few months.

It's what happened in between the public unveiling of the vulnerability and the delivery of the official patch that I want to talk about here. You see, there's no question that this vulnerability was real, and that it was being actively exploited by nasty Web sites and e-mails and instant message worms in the wild. While none of these infections reached a critical mass, they were starting to spread while most companies were out on their end of year holidays, and many people in the security community were worrying about what would happen January 2 when the business world started creaking back to life. There was a work-around (unregistering a particular DLL), but that was pretty obscure and scary for the average user.

So it was that Ilfak Guilfanov, developer of the IDA Pro disassembler and debugger, released his own patch to the world, a week before Microsoft released the official patch. Guilfanov isn't just some bozo, but a respected and experienced low-level Windows developer who took the time to understand what was going on with the vulnerability and to explain his fix. He also shipped the full source code as well as a compiled patch, so anyone could verify that the patch did what he said it did. Several security groups took him up on this, including the well-respected SANS Internet Storm Center, who unhesitatingly recommended using this unofficial patch until Microsoft's official fix was available.

Well, judging by the reactions of some others in the security community you would have thought that they were recommending boiling babies in oil. Some very vocal folks in blogland were quick to issue blanket condemnations of non-Microsoft patches, going so far as to say that you should immediately stop listening to any security professional who would recommend such a dastardly step as installing a patch from anyone but Microsoft. To hear them tell it, perfect code comes only from Redmond. (I suppose the vulnerabilities get inserted into Windows on the days that the perfect coders take a vacation.)

That attitude baffles me. If I've learned anything in the past decade of fighting security issues on my own network and its connections to the Internet, it's that evaluating vulnerabilities and fixes is a complex and individual art. No one has a monopoly on the right answers, including Microsoft. As far as I'm concerned, if you blindly apply every Microsoft patch as soon as it comes out you're just as foolish as someone who blindly applies a third-party patch without taking the time to evaluate its source, direct effects, and side effects on your own network. Getting a patch directly from Microsoft may give you confidence in the source, but it does nothing to free you of the responsibility to perform the rest of the evaluation.

Just about every time a security patch comes out, it breaks some existing application or Web site that depended on the old, insecure behavior. For most users, this isn't an issue, but if your business depends on one of the broken applications, you're in trouble. That's why even Microsoft tells you to test patches in a sandbox (such as a Virtual PC or VMware image of your typical server or workstation) before rolling them out across your organization. You need to understand, not just what the patch is supposed to do, but what it actually does on your own mix of hardware and software.

And you can apply the same skills for evaluating software to a patch created by a third party. Does it come from someone you trust, or who is trusted by someone you trust? Have you inspected the source code (hey, Microsoft doesn't let you do this!)? Have you tested it in a sandbox to make sure it only fixes the hole, and doesn't have side effects on your necessary applications? If all of those factors give you green lights, and the vulnerability is serious enough (and the WMF hole certainly was), why on earth wouldn't you deploy it?

Ultimately, if running a network were a purely mechanical activity that didn't call for judgment, we could write a computer program to do it. Until then, those of us in the sysadmin business need to use our heads, and not just take dogmatic stands based on superstition or the hope that Mama Microsoft will make it all better. We owe our users nothing less.

Did you consider the unofficial patch? Or will such things never cross your network? Let me know at [email protected].