Port 1434: SQL Server Browser — The Port That Nearly Broke the Internet

Port 1434 carries Microsoft SQL Server Browser traffic over UDP. When a client application needs to find a SQL Server instance on a machine, it sends a query to port 1434, and the SQL Server Browser service responds with the TCP port number where that instance is listening.

It sounds mundane. Service discovery. A simple query-response protocol.

But on January 25, 2003, port 1434 became the most dangerous 16 bits on the Internet.

What Port 1434 Does

Microsoft SQL Server supports multiple database instances on a single machine. The default instance listens on the well-known TCP port 1433, but named instances use dynamically assigned ports that can change between restarts.¹

This creates a problem: how does a client know which port to connect to?

The SQL Server Resolution Service, running on UDP port 1434, solves this. When SQL Server starts, it registers its instance name and TCP port with the Browser service. Clients send a UDP packet to port 1434 asking "where is the instance named X?" and the service responds with the TCP port number.²

The protocol is simple:

1. Client sends a small UDP packet to port 1434
2. The packet contains a command byte and an instance name
3. The Browser service looks up the instance in its registry
4. It responds with the TCP port and other connection information

No authentication. No encryption. Just a quick lookup to help clients find their database.

The Vulnerability

In May 2002, security researcher David Litchfield discovered multiple buffer overflow vulnerabilities in the SQL Server Resolution Service.³ The service accepted incoming data without properly checking its length. An attacker could send a specially crafted UDP packet that would overflow the buffer and execute arbitrary code on the server.

Litchfield reported the vulnerability to Microsoft responsibly. Microsoft released patch MS02-039 on July 24, 2002.⁴ The vulnerability was assigned CVE-2002-0649.

At Black Hat Briefings in July 2002, Litchfield presented proof-of-concept exploit code to demonstrate the vulnerability. His intention was to warn administrators and encourage patching.

Six months later, the patch remained widely unapplied. Including at Microsoft itself.⁵

January 25, 2003

At 05:30 UTC on Saturday, January 25, 2003, a new worm began spreading across the Internet.⁶

The SQL Slammer worm, also known as Sapphire, was remarkably small: just 376 bytes of hand-optimized assembly code.⁷ The entire worm fit inside a single UDP packet. It didn't need to write anything to disk. It existed only in memory.

The worm's logic was simple:

1. Exploit the buffer overflow in the SQL Server Resolution Service on port 1434
2. Once running in memory, generate random IP addresses
3. Send copies of itself to those addresses as fast as possible
4. Repeat

Because UDP is connectionless, the worm didn't wait for responses. Each infected server simply blasted packets at the maximum rate its network card could handle. There was no delay in the scanning loop. No throttling. Just raw speed.⁸

The Sapphire worm was the fastest computer worm in history. It doubled in size every 8.5 seconds. Within 10 minutes, it had infected more than 90 percent of vulnerable hosts worldwide.⁹

The Damage

The worm didn't carry a malicious payload. It didn't steal data or destroy files. Its only purpose was to spread.

But the volume of traffic it generated was catastrophic.

Bank of America's 13,000 ATMs went offline. Customers couldn't withdraw cash.¹⁰ Continental Airlines had to cancel flights because its ticketing and check-in systems failed.¹¹ South Korea, one of the most connected countries in the world, lost Internet and cell phone service for 27 million people.¹²

In Bellevue, Washington, the 911 emergency services system went down. The 911 data-entry terminals weren't directly connected to the Internet, but they shared servers with other city systems. When those servers failed under the flood of traffic, the 911 terminals failed too.¹³

The irony cut deep. A patch had been available for six months. The vulnerability was well-documented. The exploit code was public. And yet, when the worm arrived, it found 75,000 unpatched servers waiting to be infected.¹⁴

Why It Spread So Fast

Previous worms like Code Red spread via TCP, which requires a three-way handshake before data can be sent. Each infected machine had to wait for responses, limiting how fast it could scan for new victims.

Slammer used UDP. No handshake. No waiting. Fire and forget.

The worm's 376-byte payload fit inside a single 404-byte UDP packet (including headers). Because it ran entirely in memory and never touched disk, there was no I/O bottleneck. The only limit was network bandwidth.¹⁵

The worm's random number generator had bugs, including an OR instruction where XOR was intended, which reduced the randomness of target selection. But it didn't matter. The worm spread so fast that these inefficiencies were irrelevant.¹⁶

Some generated IP addresses were broadcast addresses, causing the packet to reach every host on a subnet simultaneously. This accidental amplification made the spread even more aggressive.¹⁷

Security Lessons

The SQL Slammer incident taught several lessons that remain relevant:

Patch management matters. The vulnerability was known for six months. A patch was freely available. Organizations that applied it were immune. Organizations that didn't learned an expensive lesson.

UDP services are dangerous. A single packet can trigger code execution without any prior connection or authentication. Services listening on UDP ports require extra scrutiny.

Network-based filtering works. Within an hour of the outbreak, many sites began filtering UDP traffic to port 1434. The worm's signature was simple and easily filterable on contemporary hardware. This bought time for cleanup.¹⁸

Minimize attack surface. The SQL Server Browser service is disabled by default in modern SQL Server installations. If you're using static ports, you don't need it. Disabling unnecessary services reduces risk.¹⁹

Port 1434 Today

Port 1434 still exists. SQL Server Browser still runs on it. The protocol hasn't fundamentally changed.

But the security posture has. Modern SQL Server installations disable the Browser service by default. Administrators who need multiple named instances can enable it, but they're expected to understand the implications. Firewalls typically block UDP 1434 from untrusted networks.

More than 20 years after Slammer, some of those emergency port 1434 filters remain in place. Network administrators who deployed them never removed them. Why would they? The port's reputation precedes it.²⁰

Related Ports