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.
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
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 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 MikeG1@larkfarm.com.
Mike Gunderloy, MCSE, MCSD, MCDBA, is a former MCP columnist and the author of numerous development books.