The MS-SQL worm: lessons for free software [LWN.net]

The MS-SQL worm has run its course and been cleared off the net. It is also, of course, another example of a proprietary software failure that did not affect Linux users except in indirect ways. Still, the worm is interesting to look at in a number of ways, and it should give free software users and developers a few things to think about.

Much has been written about how quickly the worm spread across the net. Most of the vulnerable systems had been infected within about ten minutes. With that sort of propagation speed, there really is very little that system and network administrators can do; by the time they know that there is a problem, they have already been infected. There is no time to scramble for patches, or even to pull the plug. Someday networks will have to be able to react automatically to this sort of attack; automated response systems, however, are likely to be a source of outages themselves.

The worm infected something on the order of 100,000 hosts. Given the size of the Internet, that is a relatively small number; there just weren't that many vulnerable systems which were directly reachable on the net. Even with such a small proportion of vulnerable systems, however, the worm was able to create a great deal of disruption. It is not necessary to infect much of the net to create trouble for everybody.

This suggests that the talk of software monocultures that one often encounters (including on this site) may be a bit misguided. The net, certainly, is not a monoculture of vulnerable SQL Server systems. Monocultures still increase the risk of truly devastating, global attacks, but their elimination will not necessarily make the net a whole lot safer.

There are plenty of free programs which run at least 100,000 network-exposed systems. A widespread vulnerability in any of these programs could, conceivably, be used to similar effect by a future attacker. There is a good chance, perhaps almost a certainty, that a vulnerability in free software will be used someday to trash the net. It is not an occasion to look forward too.

Still, there are aspects of the free software way of doing things that help to make this kind of event less likely. They include:

Security updates for free programs tend to be small fixes which address the vulnerability and nothing else. Most distributors put considerable effort into backporting fixes to whatever version of the program they shipped. As a result, the security updates are relatively safe and easy to install. The SQL Server fix was, apparently, part of a huge patch set which changed many things. Applying all security updates as they come out to a Linux system can be tedious and annoying, but it is also a reasonable thing to do. It has been said that companies trying to keep up with Microsoft patch sets will encounter more outages from the patches themselves than from security breaches.
The result of all this is that Linux systems are more likely to be current with their security updates. Or, at least, they have less of an excuse if they fall behind.
Many, if not most of the systems compromised by the MS-SQL worm were running a version of SQL Server that came packaged with a completely different application; some examples include the Cisco E-Mail Manager, ISS System Scanner, JD Edwards ERP, Office 2000/XP, Visio, Unicenter, and many others. Many of the people running vulnerable systems had no idea that SQL Server was even present. Free applications do not tend to drag along major subsystems in quite the same way. Further moves toward complicated applications and component architectures could change that, however.
SQL Server, by default, opens a port to the world as a whole. For the most part, free software (and Linux distributors) have learned better than that. PostgreSQL and MySQL will talk to the net, and both have had security issues in the recent past. It is a rare installation, however, which has exposed either database server to the net without deliberate action by the system administrator.

All of the above points, hopefully, indicate that free software offers some relative security advantages, especially with regard to widespread infections. We have a long way to go, however, before we can even begin to think that we are safe. Smugness is the wrong response to this episode; instead, we need to learn from it and redouble our efforts to keep it from happening to us.

(Log in to post comments)

Rate limiting connections to new hosts to slow the spread of worms

Posted Feb 8, 2003 0:17 UTC (Sat) by fgouget (guest, #4601) [Link]

There was an interesting article (which of course I can't find anymore so I'll try to explain what it said) that advocated modifying 'desktop' OSes to rate limit connections to *new* IP addresses. With each new worm it becomes more obvious that this is something worth implementing.

Note that the proposal is not to rate limit the packets you send to a given IP address. Rather it keeps track of the list of hosts your machine has sent packets to in the past, and limits the rate at which new hosts are added to that list. For instance it could keep track of the last 64 hosts (IP addresses really) and allow up to 10 new addresses to be added per second. For normal use this would have no impact as typical desktops connect to few new hosts even when surfing the web (around 3 or 4 at a time). But such a scheme would tremendously slow down the spread of a worm like CodeRed or Slammer: instead of probing 100 to more than a 1000 new hosts per second it would only be able to scan 10 new hosts per second. This would give administrators more time to react.

The best place to implement this would be in an iptables module, ipfw, in other words any firewal or router and, please, where the worms live... Windows!
And yes, you would not want to set this up on a server like lwn. But such servers usually do not spread worms.