SQL Slammer: The 376-Byte Worm That Slowed the Internet in 2003

On Saturday, January 25, 2003, shortly before 05:30 UTC, a tiny packet started circulating across the internet. Ten minutes later, most of the world's vulnerable servers were already infected and entire links were saturated. SQL Slammer (also called Sapphire) fit in just 376 bytes, less than this paragraph, and it is still the classic example of how fast a worm can move.

The flaw Slammer exploited

The target was Microsoft SQL Server 2000 and MSDE (the embedded edition bundled with many applications). These programs listen on UDP port 1434 for the SQL Server Resolution Service, which helps clients find instances on the network. A buffer overflow in that service allowed code execution with a single malformed message.

The flaw was fixed by bulletin MS02-039 (CVE-2002-0649), about six months before the worm. Proof-of-concept code had been shown at Black Hat by David Litchfield, the researcher who discovered the problem. In other words: public fix, known exploitation, and plenty of people who never applied it.

What is SQL Slammer?

SQL Slammer is a worm that exploited the SQL Server buffer overflow (MS02-039) and spread through a single 376-byte UDP packet, with no file, no attachment and no click from anyone. It has nothing to do with SQL Injection, which is a web application flaw. Here the attack went straight at the database service.

Why was it so fast?

Two design details explain the speed, according to the CAIDA study "The Spread of the Sapphire/Slammer Worm":

• UDP, connectionless. There is no handshake to wait for. The worm "fires and forgets": every infected machine sends copies to random IP addresses as fast as its network card allows.
• Everything in one packet. Because the code fit in a single message (404 bytes in total with headers), the limit was not latency but the bandwidth of the victim's link.

The result, again per CAIDA: the infected population doubled every 8.5 seconds in the first minute, the peak passed 55 million scans per second in under 3 minutes, and more than 90% of vulnerable hosts were hit in about 10 minutes. The study counted at least 74,856 distinct infected IP addresses, and the paper itself warns that this is a floor, not a total.

What were the effects of Slammer?

It did not destroy data: the damage came from traffic volume, which saturated links, took database servers down and hit services that depended on them. CAIDA lists canceled flights, interference with elections and ATM failures among the reported consequences, plus sites that lost connectivity because their bandwidth was exhausted. Since the worm lived only in memory and wrote nothing to disk, restarting the service removed it, but reinfection came within seconds if the machine stayed exposed and unpatched.

What to learn and apply today

Slammer follows the same script as other cases we have covered here: Conficker and Sasser, both exploiting flaws that already had a patch. Practical steps:

• Never expose a database to the internet. UDP 1434 (and TCP 1433) should never be reachable from outside. If you need remote access, use a VPN or an IP allowlist.
• Filter by default. A firewall that only allows what is needed would have stopped the worm at the edge. On Ubuntu, UFW in 5 steps shows the "deny all, allow what you need" logic.
• Keep an inventory. Many people did not even know they had MSDE running, embedded in other software. What you don't know exists, you don't update.
• Patch on a deadline, especially for unauthenticated remote code execution flaws.
• Segment the network so one infected machine cannot reach everything else.

The bigger lesson

In 1988, the Morris Worm showed that the internet could be brought down by code that copies itself. In 2003, Slammer showed that the response window had shrunk from days to minutes: no human reacts in time to a worm like this. Defense has to be in place beforehand, with patching, filtering and inventory. To see that logic at its limit, read about WannaCry, which repeated the pattern in 2017.

Sources: CAIDA ("The Spread of the Sapphire/Slammer Worm", David Moore et al.), Wikipedia (SQL Slammer), F-Secure and Microsoft bulletin MS02-039.