SQL Slammer: The 376-Byte Worm That Hit the Internet in 10 Minutes

At about 05:30 UTC on Saturday 25 January 2003, internet traffic around the world began to behave strangely. Within minutes, the internet's capacity was clogged in parts of Asia, and some services failed. The cause was a worm whose entire code was a few hundred bytes long. SQL Slammer, sometimes called Sapphire, became known as the fastest-spreading worm up to that time.

A very small program

Slammer was just 376 bytes of code, small enough to fit inside a single network packet. It targeted Microsoft SQL Server 2000 and the related desktop engine, through a service that listens on UDP port 1434. The flaw was a buffer overflow in the code that handled requests to that service, which allowed a crafted packet to run arbitrary code.

Because the protocol was UDP, which does not require a connection to be set up first, the worm did not need to wait for any reply. An infected machine simply fired packets at randomly chosen addresses as fast as its network connection would allow. There was no file written to disk and no payload that deleted anything. The damage came from the traffic itself.

Speed

A team of researchers, including David Moore and Vern Paxson, analysed the outbreak and published a detailed study. They found that in the early phase, the number of infected machines doubled roughly every 8.5 seconds. The worm reached about 90 percent of the vulnerable machines on the internet in around ten minutes. The total number of infected hosts was in the tens of thousands, which is small by later standards, but each one could send a very large volume of packets.

Code Red, by comparison, had needed hours to reach its peak. Slammer showed that a well-designed worm could outrun any human response, and that defence would have to rely on measures in place before the outbreak.

The effects

The impact came from congestion. The scanning traffic saturated links and overloaded routers, which in some cases failed under the load. Reported consequences included:

• Severe slowdowns and outages of internet service in South Korea.
• Problems with cash machines operated by Bank of America.
• Disruption of emergency call handling in parts of the Seattle area.
• Delays for airline booking and check-in systems.

Most of these services were not running vulnerable software themselves. They were affected because the networks they depended on were choked.

The patch had been out for months

The most uncomfortable fact about Slammer is that Microsoft had published a fix for the vulnerability in July 2002, in bulletin MS02-039, about six months before the outbreak. Many organisations had not installed it. Part of the reason was that some copies of the database engine were embedded in other software, so administrators did not know that they were running it. Another reason was an unwillingness to apply patches to database servers without extensive testing.

A second issue was exposure. A database server has no reason to accept connections from the whole internet, yet many of those infected were reachable from outside. A properly configured firewall that blocked the port would have protected them, whether they were patched or not.

The author of Slammer was never publicly identified. The code reused ideas from a proof-of-concept exploit that a security researcher had published, and the worm contained a bug in its random number generator, which limited the variety of addresses it chose. Despite that flaw, it was devastatingly effective.

Slammer also showed the difficulty of counting your own assets. Several organisations discovered that they were running database engines they had never installed on purpose, bundled into other products, and that these copies were missing from the patch inventory. When asked afterwards where the infection had entered, the honest answer was often that nobody knew a database was there. The practical lesson is to know what is running on your servers, not only what you chose to put there.

What changed afterwards

Slammer helped convince software vendors and administrators that automatic patching and default-deny network policies were needed. Microsoft continued to move toward regular monthly patch releases, and security guidance began to stress the idea of reducing the attack surface: turning off services you do not need and blocking access to everything else.

The lesson for site owners today

Your database should never be directly reachable from the internet. Web applications need to talk to their database, but only the web server needs that access, and usually only from the same machine or a private network. Opening a database port to the world is one of the most common configuration mistakes, and automated scanners look for it constantly.

1. Bind your database to the local machine or a private interface.
2. Use a firewall to block every port you do not need.
3. Keep database software updated, including versions bundled with other tools.
4. Use strong, unique database passwords and limit what each user can do.

For heavier workloads, a dedicated server gives you the whole machine.

Applying it

On shared and WordPress plans, databases are managed through Plesk and are not exposed for you to configure. If you run your own server on a VPS or a dedicated server, firewall rules and database settings are yours to control, and our knowledgebase can help you get started.