display | more...

A plastic or metal disc about an 1/8th of an inch thick with the diameter about 3/2 of that of a quarter, used to play the game Pogs. The slammer is used in the game to "slam" (hence the name) into a stack of pogs (roughly the size of the slammer, only lighter, thinner, and paper) and knock/flip those pogs over. The metal slammers, heavier and usually more effective, were considered "cheap" (ie, they gave an unfair advantage to the user), while the plastic slammers created a more equal playing field.

On Saturday, January 25, 2003, a worm seriously impeded Internet traffic around the world. Internet access was halted in South Korea, causing trading volume on the South Korean stock exchange to plummet. Bank of America’s ATM system was disrupted, as was telephone traffic in Finland, and clincal data at Beth Israel Deaconess Medical Center (BIDMC) in Boston.

The worm itself was small, file-less and resided only in memory. It contained no harmful “payload”, and did not create or delete files, and did not use e-mail, but actively scanned for vulnerable Microsoft SQL servers. Slammer’s aggressive scanning, using every available IP address, overloaded many networks. In fact, the worm impeded its own propagation by slowing network traffic.

Dubbed Slammer or “SQL Slammer”, and also known as Sapphire (F-Secure), w32.SQLexp.worm (Symantec), and Helkern (Kaspersky), the worm exploited known vulnerabilities in Microsoft SQL 2000 servers. It did not affect desktop PCs, Linux, Mac, or Unix systems. Slammer propagated itself in relatively small, 376 byte packets, which it would direct at SQL Server Resolution Service port 1434 on the following Microsoft SQL servers:

  • SQL Server 2000 RTM
  • SQL Server 2000 SP1
  • SQL Server 2000 SP2
  • Microsoft SQL Desktop Engine Version (MSDE) 2000

The underlying buffer overrun flaw may be patched with MS02-039, or by installing SQL 2000 Service Pack 3. System administrators could also block the following SQL server ports:

  • ms-sql-s 1433/tcp #Microsoft-SQL-Server
  • ms-sql-s 1433/udp #Microsoft-SQL-Server
  • ms-sql-m 1434/tcp #Microsoft-SQL-Monitor
  • ms-sql-m 1434/udp #Microsoft-SQL-Monitor


Among the companies affected by the SQL Slammer worm, despite existing patches supplied by Microsoft, because their systems administrators "didn't get around to it": Microsoft itself.


  • http://zdnet.com.com/2100-1105-982226.html
  • http://www.cnn.com/2003/TECH/internet/01/27/worm.why
  • http://www.techtv.com/news/security/story/0,24195,3415704,00.html

It is easy enough to pontificate after the fact about what went wrong and who made which mistakes. So I shall pull out my soapbox without further ado.

There were several contributing factors to the general mayhem that reigned for a short while on the 25th January. The most worrying is that so many administrators (an estimated 75,000) didn't firewall the relevant ports as listed in the above writeup.

The first important thing anyone running a server on the Internet should know is this: only open the ports you need, and close everything else. For a single server running a website and mail, these ports are 80 for http, maybe 21 for ftp, 25 for smtp, 110 for pop3, and, if you need to allow secure surfing, port 443 for SSL/TLS. Windows 2000 has the capability for basic firewalling built in. Windows NT does not, but should always have a firewall between it and the Internet.

Next I'll fling some impressive statistics your way:

[Slammer] was the fastest spreading computer worm in history. It spread throughout the Internet and infected most of the vulnerable hosts that could be found within ten minutes.


During the first three minutes of the worm's spread, the number of infected machines doubled roughly every 8.5 seconds [...] the worm hit its full scanning rate of around 55 million scans per second at around three minutes after the attack began at roughly 05:30 GMT on Saturday.


In hitting this impressive rate of infection, out-pacing even the theoretical Warhol Worm, Slammer generated an enormous amount of traffic. According to anecdotal evidence, a handful of infected machines managed to saturate a 100 Mbps Ethernet link - something most servers should never have to deal with.

This level of traffic caused problems for some of the routers that make up the backbone of the Internet. Some became so bogged down that they couldn't keep up with their BGP duties, and became unreachable from the rest of the Internet. This second factor would be slightly ironic, if it hadn't knocked Korea off the net along with Bank of America's ATM network1. In a few cases, some heavily infected subnets cut themselves off from the rest of the Internet by overloading routers, hence slowing the infection rate.

The second and equally important thing that anyone running a server on the Internet should know is this: keep up to date on patches. This particular tale of woe that comes straight out of RISKS digest, and is an illustration of how even little mistakes cause big problems.

Security vulnerabilities such as those used by Slammer work by exploiting problems in programs. Patches (or, as Microsoft calls them, ''hotfixes'') correct the problems in the files that are make up these programs. Microsoft has made a command line tool available, ''hfnetchk''2, that is supposed to check a given system for the presence of all available patches, and thereby verify that the computer is as secure as possible. On running, hfnetchk parses a file downloaded from Microsoft's website called ''mssecure.xml'' that contains an up-do-date list of all security patches published by Microsoft3.

As of Sat, 25 Jan 2003 09:45:38 -06004, Microsoft's version of mssecure.xml contained no mention of patch that fixed the vulnerability exploited by Slammer. Administrators using hfnetchk to check their servers would see no mention of this missing patch, and hence remain vulnerable.

It's this kind of thing that make sysadmins grind their teeth in frustration. Sometimes at the companies who supply them with software, but more often at the members of their own profession who couldn't tell a firewall from an iron curtain.

1: What I want to know is, WTF was an ATM network doing anywhere near the big bad Internet?!‽
2: hfnetchk: HotFixNETworkCHecKer.
3: You can download the current version (at 1.4 MB) from
4: The time was taken from this message posted to ntbugtraq by Eric Schultze of Shavlik Technologies, the external developers of hfnetchk:

Sources not mentioned elsewhere:

The first portion of this writeup is based on [1], below. The second part is my own analysis.

Why did Slammer propagate so quickly?

Slammer's rate of infection (see Jetifi's writeup above) was unparalleled. The entire worm was 376 bytes. Infection was the simple matter of receiving a UDP packet containing the worm on the right UDP port of a vulnerable host. Upon infection, the worm would immediately start scanning IP addresses randomly (Almost; the PRNG was apparently coded incorrectly, leading to Slammer to scan only 1/4 of all IP addresses; this analysis also shows why this did little to limit the damage. Additionally, even with a correct PRNG, the seed was partially time-based the tremendous rate of infection would mean that many copies would use the same seed, leading to their using the same selection of IPs. This would act to lower the rate of infection during the peak spread of the worm.). The worm would transmit a UDP packet containing itself to each IP address, at the right port.

If a vulnerable host were present at the scanned IP address, it would immediately enter the same loop of scanning IPs randomly.

None of which is enough to explain the rate of infection: Slammer was (to quote [1]) "bandwidth-limited", not "latency-limited". That is, Slammer could (quite easily) saturate a 100Mbps ethernet link. The reason for this is the trivial nature of the UDP packets. TCP is a connection-oriented protocol: first a "connection" is set up, then data is streamed along it. Setting up a connection requires the TCP three-way handshake (aka SYN - ACK). Even if the remote host refuses a connection on the port, a round trip of packets is required. In other words, had Slammer utilized a TCP connection to spread, every attempt to infect an IP address would have to wait at least one round-trip time to execute. From where I'm sitting, pinging Google has a round-trip time of 1/4 second.

Slammer used UDP packets, without having to wait for a response from the host. These were literally "fire and forget". A 404-byte UDP packet was enough to infect -- and it immediately caused the infected hosts to fire 404-byte UDP packets, usually as fast as it could. Thus, Slammer wasn't limited by latency (the length of the pipe to the target), but by bandwidth (the width of the pipe, mostly at the source). On an unloaded machine (and Slammer hit during a weekend, of course), it could easily fill the entire 100 Mbps ethernet link with its traffic.

A TCP-based worm could also conceivably be bandwidth-limited, if it initiated numerous TCP connections in parallel. This would likely require rewriting portions of the TCP/IP stack, making the worm larger (threading isn't up to the task of handling so many simultaneous connection attempts; neither, for that matter, is the operating system). State would probably also have to be kept. Even if it worked (and someone were willing to code it all, the worm would be much larger -- saturating a 100Mbps link with a 400-byte worm means 25,000 IPs attacked every second; saturating it with a 40Kbyte worm means 250 IPs a second...

Why did Slammer spread at all?

Having explained above the extraordinary effectiveness of Slammer's infection, I'll now turn to the other side, and examine why it could spread at all.

Every machine infected by Slammer uses up a huge amount of bandwidth. Eventually, the machine will get stopped (even a reboot is enough to stop the current infection by Slammer -- though of course re-infection is a definite possibility). Either the sysadmin will switch it off, or it will be rebooted, or the ISP will disconnect it, or ... Let's assume an infected machine runs for 24 hours.

A simple probabilistic model for the early stages of infection is this: In early stages, we can ignore re-infection, as so few machines are already infected. An infected machine attacks IPs, infecting machines at some of them, until it is stopped. Assume that true random numbers are used (untrue, but reasonable), and also that IPs chosen by different machines are independent (untrue, and unreasonable; in truth, this factor lowers the infection rate even more). Finally, assume all machines in the network are alike -- connected by a 100Mbps link to the Internet (again, untrue -- but machines on dialups are probably not going to contribute significantly to infection, and machines with larger links are probably in heavy use, and won't manage to utilise much more than 100Mbps for worm traffic).

So the number of different machines infected by one machine is given by some distribution z on the natural numbers; this distribution is the same for all machines, and the infections of each machine are independent. The random process describing this scenario is the Galton-Watson process. Without going into much detail, the process dies out if the average number of "children" of an infected machine is below 1 (μ(z)≤1). If μ(z)>1, then there is some positive probability of infection continuing forever; in this case, the infection grows roughly exponentially, with rate μ(z).

OK, we're all set! An infected machine will send 25,000 packets (400 bytes each) a second, for a total of 100Mbps. In a day, it will scan around 2*109 IPs, hitting half the IPs on the Internet. Clearly, in this mode μ(z)>>1 if there are any vulnerable machines out there at all.

Suppose now we only allow 1 minute before an infected machine is shut down. An infected machine scans 1,500,000 IPs before being shut down. Recall that many IPs are unused (this is unfortunately true, regardless of the IP address shortage). If only 1 in 1000 IPs is used (i.e. ~2 million hosts on the Internet) and the probability of a host being vulnerable is 1/5000 (i.e., running a vulnerable SQL Server or similar product, not behind a firewall or behind a firewall not blocking the dangerous port), then μ(z)<1, and we're safe -- the infection will die off by itself. But, even with these optimistic numbers, if infected machines are allowed to run for 10 minutes, μ(z)=3.333... > 1, and we'll be hit badly (the number of infected machines will roughly triple every 10 minutes).

Slammer had it too easy. It could have been 10 or 100 times larger, maybe even utilizing some primitive TCP stack, and still have made an impact.


  1. The Spread of the Sapphire/Slammer Worm, David Moore (CAIDA & UCSD), Vern Paxson (ICIR & LBNL), Stefan Savage (UCSD CSE), Colleen Shannon (CAIDA), Stuart Staniford (Silicon Defense) and Nicholas Weaver (Silicon Defense & UC Berkeley EECS).
On Saturday the 25th of January 2003, the Internet as a whole became very slow. Servers suddenly became very sluggish, or unavailable, and although this did not last for long (in most cases about 4 hours), the sudden glimpse of what a relatively simple piece of code can do was frightening.

The SQL "Slammer" Worm

What was scary about this worm was not it's malevolence (See below), but the incredible speed at which it propagated. For most people, the attack appeared to be binary in nature - either you had the worm and therefore had an almost complete Denial Of Service, or you didn't. Newscasters pointing at maps showing the spread of infection were on completely the wrong track - the worm didn't see the machines in terms of the distance between them, it simply saw the links through which it could spread. It also spread in a matter of minutes, far too short a time frame for any warning to be given.

Because the worm used UDP instead of TCP, the rate of infection was far faster than many companies would expect - leading them to believe that they were targeted specifically. The worm did not target anyone in particular. While it is possible that certain computers were initially targeted, it is unlikely that they were targeted for any reason other than that they had fast Internet connections. One server, so infected, could then infect any number of other computers, which would in turn infect more computers, making the propagation of the worm virus-like in nature.

How it worked

The design of the worm was laughably simple - Once on the infected machine, use the random number generator function to generate random numbers between 1 and 255. Then assemble a complete IP address from these numbers, and broadcast a copy of the worm out to that IP address on port 1434 UDP. Repeat. No damage was done to that machine, nor any other infected machine. The damage came from the fact that the computer was trying to reach a random address as often as it possible could - on a gigabit network interface, this was about 100 000 packets a second, or 300 megabytes of traffic every second. This was enough to take down most networks, but things became even more stressed whenever a packet was generated with 255 values in it, as these broadcast out to every interface on the network. A similar attack using TCP instead of UDP would have been far slower, as TCP is a connection-oriented protocol. Because of it's simplicity the worm was also laughably easy to remove - since it was entirely memory-based, it could be removed simply by rebooting the machine. Once the relevant patches were applied, the system could be considered clean.


The worm worked on a vulnerability in SQL Server - a vulnerability that was not only known about, but for which there was also a fix. Microsoft had had a patch available for 6 months. Why was this patch not applied? When it comes to applying patches, system administrators soon find that while it is possible to patch your software with every available fix as soon as it comes out, this soon becomes more trouble than it is worth. Sometimes the patches bring in new flaws and vulnerabilities, and there is also a chance that they may render the entire machine inoperable. In the end, it is better to face a possible outage from an attack than to experience possible outages every time a patch is applied. What many people do not realise is that a version of SQL Server also ships with MSDE (Microsoft Database Embedded) applications, such as Visio, McAffee's Virus Manager, some Cisco Software management products, Visual FoxPro and many others. All of these products were vulnerable to the attack, and it is therefore NOT the servers on the Internet that were primarily responsible for this attack - it was the desktop machines. In any corporation there are usually less than ten servers, but there are hundreds of client computers, any number of which could be running a MSDE application without even realising it.


After any such incident, there is always a lot of finger pointing, and this one was no different. Microsoft was blamed - though their public statement clearly points out that the patch was available to anyone from July 2002. They showed, I feel remarkable restraint in not writing "I did warn you and you didn't listen - nah nah nah nah" in large letters all over the page. On the other hand, it was their software that had the vulnerability in the first place. Many governments and corporations felt that they were targeted specifically due to the incredible speed at which the worm spread through their network - not realising that the worm used UDP, which is far faster than TCP. Universities were blamed for the large volume of infected packets that came through their links, but people failed to realise that if a machine was infected, it would use any line available, and the volume is determined directly by the speed of the line available. So the universities, which had high-speed connections, broadcast more than any local home user. Everybody told everybody else to remember to always apply patches, forgetting that the reason that patches are not applied is because occasional outages such as that caused by the Slammer worm are preferable to the more frequent outages caused by the constant application of patches. Ultimately, no major damage was done, and the systems in question sit, newly patched and waiting for the next attack exploiting another vulnerability. The most violent attack on the internet yet was over so quickly that most people didn't even know it had happened.

Log in or register to write something here or to contact authors.