Patches? We Dont Need No Stinkin Patches!

 
 
By Larry Seltzer  |  Posted 2003-03-05 Email Print this article Print
 
 
 
 
 
 
 

Security Supersite Editor Larry Seltzer isn't worried about Slammer or the Sendmail flaw. He keeps his patches and antivirus up to date, and he's never been successfully attacked. Why can't corporate administrators do the same?

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.
 
 
 
 
Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel