What Was SQL Slammer? The Worm That Fit in a Single Packet
Three hundred and seventy-six bytes.
Not the loader. Not the first stage. The entire worm — header, exploit, propagation logic, everything — fitted inside one UDP packet.
What was SQL Slammer?
SQL Slammer, also catalogued as Sapphire, appeared on 25 January 2003. It exploited a stack buffer overflow in the Microsoft SQL Server Resolution Service, reached over UDP port 1434.
It infected an estimated 75,000 hosts, and it reached roughly 90% of all vulnerable machines within ten minutes. Population doubled about every 8.5 seconds. Nothing before or since has spread at that rate.
Why the size is the story
Every worm before Slammer opened a TCP connection. TCP requires a handshake, which means the attacking machine sends a packet and then waits for a reply before it can continue. Propagation speed is therefore governed by round-trip latency, and latency is a property of distance and congestion that no amount of clever code improves.
Slammer used UDP. There is no handshake. It sent a packet and immediately sent the next one, to a different random address, without ever knowing or caring what happened to the first.
That changes the limiting factor from latency to bandwidth. A single infected machine on a decent link could emit tens of thousands of packets per second. The worm's spread rate stopped being a function of the internet's geography and became a function of how much pipe the infected machines collectively had.
Fitting in one packet is what made UDP possible. A larger worm would have needed fragmentation or a session, and the whole advantage evaporates.
It had no payload
This is the part that reframes it.
Slammer did not encrypt anything, delete anything, install a backdoor, steal credentials, or leave a persistent presence. It did not even write itself to disk — it lived only in memory, and a reboot cleared it entirely.
All it did was generate random addresses and send copies of itself to them, as fast as the hardware allowed.
That was sufficient to:
- Take Bank of America ATMs offline across the United States.
- Knock out a Seattle emergency call centre, forcing dispatchers back to paper.
- Ground Continental Airlines flights when electronic ticketing and check-in stopped responding.
- Remove South Korea from the internet for most of a day.
None of those were targets. None of them were even necessarily running SQL Server. They were collateral from routers and links saturated by scan traffic. The denial of service was a side effect of the worm trying to reproduce.
The nuclear plant
The detail that gets repeated most is the Davis-Besse nuclear plant in Ohio, where Slammer disabled a safety parameter display system for about five hours.
The honest version has an important qualification: the plant was already offline for unrelated maintenance, and there was an analogue backup system that remained functional throughout. It was not close to an accident.
What it did demonstrate, and the reason it is still cited in industrial control security twenty years on, is how the worm arrived. The plant's process network was supposed to be isolated. Slammer entered through a contractor's T1 line that connected into the corporate network behind the firewall, bypassing the perimeter entirely. The isolation existed on the diagram.
Correcting the record
The patch had been available since July 2002. Slammer arrived six months later.
The reflex is to file that under negligence, and it is worth being fairer than that. Patching a production database server in 2002 meant a service restart, a maintenance window, and a change advisory board, for a fix to a component many administrators did not know was listening — the Resolution Service ran on machines where nobody had deliberately installed SQL Server at all, having arrived bundled inside other products.
The real change Slammer forced was not "patch faster." It was the recognition that internet-facing UDP services with no authentication are a category of thing you should not have, and the beginning of the end for the assumption that a firewall is a security boundary.
What is still true
Nothing has matched its speed, and that is mostly not to our credit — it reflects that the specific combination Slammer needed (a tiny exploit, a connectionless protocol, and an enormous population of unpatched identical hosts) has not lined up again in the same way.
The measurement work it prompted, particularly the CAIDA analysis of the first minutes, is still the reference for how fast a worm can theoretically propagate. The answer was: faster than any human process can respond, which is why the response model moved to automation.
Further reading
- Moore, Paxson, Savage, Shannon, Staniford and Weaver — Inside the Slammer Worm (IEEE Security & Privacy, 2003). The definitive measurement.
- CAIDA's analysis of the first minutes of propagation.
- Microsoft Security Bulletin MS02-039, July 2002.
- The NRC information notice on Davis-Besse, for the accurate version of the nuclear plant story.
EXHIBIT 0012 — SQL SLAMMER
We put it on a shirt. One small datagram, drawn as a technical plate, alone in a great deal of empty space — with a doubling curve climbing away behind it.
Most people will notice the empty space. A smaller number will understand that the empty space is the point.
That's the whole idea.