eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The past year or so had been marked by few significant Internet attacks—and none of the caliber of Code Red, ILoveYou and other pioneering attacks of years past.
Then Slammer/Sapphire hit the Internet in January. The Microsoft SQL Server worm was definitely a technical innovation: Almost unbelievably, the majority of the systems affected by it were infected in the first 10 minutes of the attack. This is pretty amazing and reason to be concerned about the potential for future attacks that employ Slammers techniques.
But many of the reactions to Slammer were irrational beyond belief. Tops in my book is the claim that this incident shows that Microsofts approach to patching security holes is a failure. How else to explain the fact that Microsoft had announced this vulnerability six months ago and released a patch for it, and still thousands of SQL Server systems, some even within Microsoft, were unpatched?
This argument is usually followed by the syllogism that if Microsoft had written perfect software to begin with, there would be no need to patch it. (You need a really high-priced security consultant to come up with genius like this.)
The more recent revelations of a serious vulnerability in the popular Sendmail SMTP server brought me right back to Slammer. If, six months from now, a major worm exploits this vulnerability and enough servers are left unpatched to let it spread, will that be a failure for Sendmail (and Red Hat and SuSE and everyone else who distributes it)? Or will it be a failure of the administrators paid to maintain their systems?
Of course, no software of any meaningful complexity is perfect, and all reasonably complex applications have bugs in them. And while both Slammer and the Sendmail flaw exploit some bad programming practices in SQL Server, all buffer-overflow vulnerabilities reflect a bug somewhere. All major applications have bugs, and all of them use patches or version upgrades to address them. If the authors of the attack had found an overflow in Apache, they could have introduced the bug as easily, and it would have spread just as quickly.
I look at what happened, and I have no trouble blaming the administrators who went months without applying a simple patch for what was known to be a serious vulnerability. Obviously they always had something more important to do, right? This is like saying you dont have time to brush your teeth because you could be at work making money instead. Some things are important enough that you make time for them.
Microsoft had not created an installer program for the patch, but applying the patch involved changing one file and restarting the server. “But I didnt know about the patch,” some will say. This is also not much of an excuse, since Microsoft publicizes these problems and other sources, like BugTraq, and NTBugTraq, which have their own e-mail notification systems, re-publicize them. If you dont know about these then you must be trying to avoid security information. To join the Microsoft mailing lists, go to this page.
Technical security discussions have been rich with ideas for how to prevent such problems in the future. Some of the ideas are technically interesting and have potential, but few of them are going to be in place in mainstream systems any time soon. In the meantime, read your email and take the time to do security maintenance on your systems.
Security Supersite Editor Larry Seltzer has worked in and written about the computer industry since 1983.