To patch or not to patch: the third-party question

Microsoft Internet Explorer and Microsoft Office have been under a zero-day attack barrage for the last few months. In what is becoming a familiar cycle, Microsoft releases its new monthly patches on “Patch Tuesday," only to have a handful of new zero-day public exploits announced a few days before or after. The hackers want to maximize the time their zero-day exploits exist in the wild before Microsoft has a patch for it.

Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft

Microsoft, using customer feedback, automated tools, and its participation in an anti-virus consortium, measures how widespread each new zero-day attack is. If the attack is truly widespread, Microsoft rushes the normal patch cycle and delivers the fix before the next Patch Tuesday release. If the exploitation is not widespread, which has often been the case, Microsoft waits until the normal Patch Tuesday cycle. Taking its normal time to create and test a patch normally means more stable patches (it’s even been a tough road there for Microsoft lately…but that’s another story).

Microsoft gets a lot of grief when it decides to wait until the normal Patch Tuesday cycle to patch a new zero-day exploit that is loose in the wild. The press is all over the latest bug, self-feeding on the hype. Even one of my favorite sites, dshield.org, gets on the bandwagon prematurely, dogging Microsoft for not delivering instant patches while millions of malicious exploits are supposedly spreading. In most of these recent cases, the "millions of malicious exploits" turned out to be fewer than 100 in the wild.

But perception is reality, and Microsoft takes it on the chin while the latest patches are being debugged. Whether or not the threats do become moderately widespread, consumers are left hanging in the wind until an official patch is deployed or some other offsetting protection (such as setting an applet kill bit) can be advertised and deployed. Most consumers never deploy alternate protections, so they remain unprotected until the official patch is deployed.

Because of this, several third parties have begun releasing protective patches to close holes until the official patches are released. Central to this phenomenon is the newZeroday Emergency Response Team (ZERT). ZERT is a talented team of programmers and security experts dedicated to creating patches when the official patches lag behind popular demand. ZERT’s ZProtectorframework allows third party Microsoft Windows patches to be created and deployed, while eliminating the need for the third-party patch to be uninstalled once a vendor patch becomes available.

Other professionals, such as Dr. Jesper Johansson, a former top Microsoft security employee, recommend offsetting defenses that defang zero-day code. Jesper recently came up with some solid security fixes that could be quickly deployed using group policy.

Microsoft and many other security experts warn customers against deploying third-party patches and fixes. Most customers should strongly consider this advice. For one, third-party patches and fixes are often not as thoroughly tested as well as an official patch. A Microsoft source once told me that each Internet Explorer security patch undergoes thousands of regression tests before it can be released.

It’s also true that third-party patches have caused more problems than they solved. Even Jesper’s excellent VML protection script caused problems on a certain class of Windows computers in a common patch scenario.

But with the official warnings in mind, I feel that any company with a knowledgeable administrator who has the time to test a third-party patch or fix thoroughly can benefit using third party patches and advice in times of crisis. Some of these sources are quick to respond if something does go wrong: Jesper made updates to his fix-it advice as soon as he became aware of the problems, for example; ZERT appears to be making the right choices in how it applies its patches, not modifying the original impacted executable.

In my opinion, if a widespread exploit is high risk in your environment, you should consider testing and deploying a third party patch or fix. Management should be made aware of the nature of the third party patch, the risks, and give final approval. And as with any new patch -- even official patches -- you should test thoroughly and have a tested reversal plan in case the medicine is worse than the disease.