Its the beginning of your regular workday. You sit down at your desk and start going through the breaking tech news and looking through e-mail alerts. A big story about a new and dangerous Internet worm immediately catches your attention because the worm exploits an old security problem in Windows servers and you know that you havent applied the patch for that specific hole. Thinking theres no time like the present, you head to the data center to apply the patch to your systems.
You download and apply the necessary patch, and since the systems dont require constant uptime, you decide to reboot them just to make sure the patch is applied properly. But something is wrong, and the systems wont boot up.
Did the systems fall afoul of the worm? Were you too late in applying the patch, or did you apply it improperly?
Nope. The problem isnt the worm—its the patch.
Something very close to this scenario recently played out for many IT managers who were attempting to protect their systems but instead damaged them. A patch that Microsoft provided to fix the SSL vulnerability in Windows servers contained a bug that would prevent certain systems from booting up properly.
You probably think Im planning to bash Microsoft here for releasing a faulty patch, but Im not. Yes, Microsoft should have done a better job testing the patch, but this isnt the first time a patch has had a bug in it.
Part of the problem is the term “patch” itself. It brings to mind things such as Band-Aids or spackling, and people think of it as an easy fix. But most patches arent like Band-Aids; they are more like open-heart surgery. Often, patches are essentially full rewrites of an application or program—and any time you rewrite a program, theres a chance it will have bugs.
Its bad enough that many users have this perception of patches as a simple fix, but Im starting to see the same attitude from software vendors. Microsoft officials have said that they plan to implement automatic software patching for forthcoming versions of Windows, stating that it will take the burden of keeping systems up-to-date off users.
Whenever Im presented with automatic patching schemes during a vendor presentation, I inevitably mention that many of our readers say they wont implement patches until theyve had time to test them, often waiting months to make sure there are no hidden problems with the patch.
When I mention this, vendors typically respond that the automatic patching can be turned off. But this response often is accompanied by a little chuckle and a shake of the head, as if to say, “When will these old-school admins learn?”
Well, guess what: These old-school admins are right. Patches arent to be trusted.
When Microsoft announced it would include automatic updating as a preferred (meaning default) option in the forthcoming Windows XP Service Pack 2, many in the security community applauded the move. I can understand their enthusiasm. I, too, find it very frustrating when a worm or virus wreaks havoc on the Internet by exploiting a security hole that has had a patch available for months.
But while automatic patching sounds like a good idea, the recent problem with the SSL patch should be a wake-up call. Maybe this will remind people that patches arent to be taken lightly; they arent simple fixes that can be distributed and deployed without users even knowing their system has been changed.
Yes, nine times out of 10, automatic patching will be a benefit and will prevent the spread of viruses and worms that would have exploited holes that users wouldnt have patched manually. But what about that tenth time?
Imagine a buggy patch being automatically deployed and instantly bringing down and damaging millions of systems. Something like that would make most worms and viruses look like a minor annoyance.
This is a worst-case scenario, of course. But recent history has shown that worst-case scenarios can happen. So lets keep patching in perspective and stick with education and persistence to help users keep their systems secure. And lets leave “automatic” out of patching.
Labs Director Jim Rapoza can be reached at [email protected].
Be sure to add our eWEEK.com security news feed to your RSS newsreader or My Yahoo page: