Summary

  • Microsoft had issued a correction for the SQL Server 2000 Resolution Service in July 2002, yet SQL Slammer still found a large reachable population in January 2003 and infected more than 90 percent of vulnerable hosts it could reach within ten minutes, according to CAIDA.
  • The event separated four authorities that a bulletin could not collapse: the publisher could repair code, distributors could reveal embedded MSDE copies, owners could change and expose running instances, and network operators could pre-authorise containment before a human decision arrived too late.

A repair existed; retirement did not

Microsoft published Security Bulletin MS02-039 on 24 July 2002. It described unchecked buffers in the SQL Server 2000 Resolution Service, which listened on UDP port 1434 so clients could locate named database instances. A crafted request could overwrite a stack buffer and execute code with the SQL Server service account's privileges. SQL Server 2000 and Microsoft Desktop Engine 2000 were affected.

The bulletin did more than warn. It supplied a patch, identified a file version administrators could check and advised blocking UDP 1434 where the service was not required. A cumulative patch published with MS02-061 on 16 October also contained the fix. By the calendar, defenders had months.

But a publication date is evidence about the publisher, not the installed base. Microsoft could make corrected bits available and explain their installation. It could not know every product that had brought MSDE onto a machine, choose every maintenance window or make an independently administered service load the new code. The old implementation retained authority wherever it was still running and reachable.

That distinction is Running-Code Primacy without metaphor. The bulletin proposed a new state. The loaded service decided which state existed.

One packet removed the waiting time

SQL Slammer, also called Sapphire, began spreading shortly before 05:30 UTC on Saturday, 25 January 2003. Its body was 376 bytes. CAIDA describes a 404-byte UDP/IP packet once headers were included. On reaching a vulnerable Resolution Service, the packet exploited the overflow and caused the new host to send the same body toward pseudorandom Internet addresses on UDP 1434.

There was no connection establishment and no need to hear from an attempted target before moving to the next. A TCP scanner normally spends time opening sessions or timing out. Slammer's inner loop simply transmitted. The infected host's output path, not network round-trip time, became the principal limit.

CAIDA directly observed one host sending about 26,000 probes per second and estimated an early average of roughly 4,000 per infected instance. About three minutes into the outbreak, the aggregate scanning rate exceeded 55 million packets per second. More than 90 percent of the reachable vulnerable population was infected within ten minutes.

Those figures need their boundaries. CAIDA recorded 74,856 distinct infected addresses during the first 30 minutes, but called that a lower bound. Defects in Slammer's pseudorandom generator meant a monitor could miss entire address cycles, and one early trace failed after roughly two minutes and forty seconds. The right claim is not an exact global census. It is that measured propagation completed its decisive phase before an ordinary human escalation path could act.

The attack came from inside the affected network

Slammer was not memcached reflection. It did not need to write a victim's address into a request and induce a third party to return a larger answer. An infected SQL Server originated its own scan traffic. The observed variant had no separate destructive payload; aggressive propagation was enough to cause harm.

At many sites, one or a few compromised machines tried to transmit at the highest rate available. They saturated the first shared bottleneck and denied connectivity to unrelated systems behind the same link. CAIDA also identified a punishing combination for network equipment: high byte volume, high packet rate and a rapidly changing set of destinations. The worm even interfered with its own growth as infected senders competed for scarce capacity.

This changes the accountability map. A perimeter policy designed only to keep attacks out is incomplete when an overlooked internal runtime can consume the organisation's entire egress. A central scrubbing provider is not the first control. The first useful controls may be local segmentation, outbound anomaly detection, fair queuing, rate limits or an emergency rule that isolates one host without silencing every service on the site.

Embedded software broke the obvious inventory

MSDE 2000 mattered because it was a database engine that other products could install. An administrator who did not believe the organisation operated “SQL Server” could still possess the vulnerable Resolution Service as an application dependency. CERT/CC explicitly warned that products including MSDE 2000 were affected.

This is the software-lifecycle failure that a vulnerability count misses. The publisher knows the component. The distributor knows where it was bundled. The application owner knows which business function depends on it. The network team sees UDP 1434. None of those views alone is a reliable inventory.

A patch campaign therefore needs an executable identity, not only a product label. Which process is listening? Which binary is loaded? Which application installed it? Who accepts the maintenance risk? Which clients genuinely need the discovery service? Can an external or internal probe reach it? The answers form the adoption record.

Microsoft's later patch history also shows why “just install it” is not a complete governance rule. MS02-061 was reissued after the original package combination could interfere with SQL Server operations in some circumstances; Microsoft integrated an additional non-security fix and a new installer. That does not excuse leaving the vulnerability open. It demonstrates why the party carrying operational consequences must test and schedule a real change instead of treating availability as deployment.

Filtering arrived in time for recovery, not prevention

CAIDA reported that many sites began filtering UDP destination port 1434 within an hour. Slammer offered unusually favourable conditions: its packet was easy to identify, the port was narrow, and blocking it often harmed little legitimate Internet traffic. Even then, the earliest human filtering began after almost all susceptible hosts had already been infected.

Filtering still mattered. It reduced continuing scan load and helped networks recover. Yet it could not retroactively prevent compromise, and a border rule could miss propagation between internal segments. Cisco's response guidance accordingly distinguished router ACLs from controls that could act within a VLAN, and noted that some organisations legitimately needed the Resolution Service. Scope had to follow the actual dependency.

The lesson is not “automate everything”. It is to pre-authorise a narrow response whose conditions are observable. If a host suddenly emits thousands of same-size UDP packets per second to changing destinations, a local policy can rate-limit, quarantine or place that host behind a restricted path. The threshold, affected segment, exception list, evidence capture and rollback remain under the network owner's control.

That is Minimum Initial Specification applied to machine time. The common invariant is modest: know the vulnerable runtime, remove unjustified reachability and stop one node from monopolising a shared network. Local operators retain the future decision about tools and topology.

What counts as adoption

For the software publisher, adoption evidence begins with an unambiguous corrected version and a safe installation path. For a product distributor, it includes a component inventory and a notification route that reaches customers who may not recognise the embedded engine. For an application owner, it is the loaded version, exposure test and documented dependency. For a network operator, it is flow evidence showing that one endpoint cannot take the link and a drill showing that isolation preserves unrelated service.

These proofs cannot pay one another's debts. A firewall may hide a vulnerable service without correcting it. A patched service may still be needlessly public. An inventory entry may be stale. A quarantine rule may be too broad to use during a live event. Each control answers a different question.

The evidence also sets a limit on institutional ambition. Microsoft did not need authority over every customer's network to publish a repair. Network operators did not need to rewrite Microsoft software to protect shared capacity. Coordination worked best where each actor exposed enough state for the next one to decide, while the party bearing the consequence kept the execution right.

Evidence limits

The record supports an already-published fix, a one-packet UDP worm, a lower bound of 74,856 observed infected addresses and an infection wave measured in minutes. It does not show that every SQL Server or MSDE installation was exposed, that 74,856 was the complete population or that every reported public disruption had the same causal chain. It does not show source spoofing, reflection, data theft or a destructive payload in the observed variant.

The durable finding is narrower and more useful. A patch can exist for months while the vulnerable implementation remains authoritative in running systems. When propagation is faster than human permission, leadership must allocate limited automatic powers before the event—and demand proof from binaries, sockets, flows and drills. Publication begins repair. Adoption retires the old code.

Sources