To patch or not to patch – that is the question

Test patches thoroughtly, says Roger A Grimes

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 maximise the time their zero-day exploits exist in the wild before Microsoft has a patch for it.

Microsoft, using customer feedback, automated tools, and its participation in an antivirus 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 (even this has been a tough road 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 favourite 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 alternative 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 new Zero-day Emergency Response Team (ZERT). ZERT is composed of 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 Jesper Johansson, a former top Microsoft security employee, recommend offsetting defences 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 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 from using third-party patches and advice in times of crisis. Some of these sources are quick to respond if something does go wrong. For example, Jesper makes updates to his fix-it advice as soon as he becomes aware of the problems. And ZERT appears to be making the right choices in how it applies its patches, by 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 and 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 turns out to be worse than the disease.

Join the newsletter!

Error: Please check your email address.

Tags securitypatchSecurity ID

More about Microsoft

Show Comments
[]