The SQL slammer worm is a computer virus (technically, a computer worm) that caused a denial of service on some Internet hosts and dramatically slowed down general Internet traffic, starting at 05:30 UTC on January 25, 2003. It spread rapidly, infecting most of its 75,000 victims within 10 minutes. Although titled "SQL slammer worm", the program did not use the SQL language; it exploited two buffer overflow bugs in Microsoft's flagship SQL Server database product. Other names include W32.SQLExp.Worm, DDOS.SQLP1434.A, the Sapphire Worm, SQL_HEL, and W32/SQLSlammer.
Computer Virus
The virus is a piece of program code that, like a biological virus, makes copies of itself and spreads by attaching itself to a host, often damaging the host in the process.
Computer Worm
A computer worm is a self-replicating computer program, similar to a computer virus. It is self-contained and does not need to be part of another program to propagate itself.
According to NSF DARPA, Silicon Defense, Cisco Systems, AT&T, NIST, and CAIDA members. Sapphire's spreading strategy is based on random scanning -- it selects IP addresses at random to infect, eventually finding all susceptible hosts. Random scanning worms initially spread exponentially rapidly, but the rapid infection of new hosts becomes less effective as the worm spends more effort retrying addresses that are either already infected or immune. Thus as with the Code Red worm of 2001, the proportion of infected hosts follows a classic logistic form of initially exponential growth in a finite system. We refer to this as the random constant spread (RCS) model.
W32.SQLExp.Worm attacks a vulnerable system
Sends itself to the SQL Server Resolution Service, which listens on UDP port 1434
Takes advantage of a buffer overflow vulnerability that allows a portion of system memory to be overwritten. When the worm does this, it runs in the same security context as the SQL Server service.
Calls the Windows API function, GetTickCount, and uses the result as a seed to randomly generate IP addresses.
Opens a socket on the infected computer and attempts to repeatedly send itself to UDP port 1434 on the IP addresses it has generated, by using an ephemeral source port. Because the worm does not selectively attack the hosts in the local subnet, large amounts of traffic are the result.
Protect your system against the Slammer worm
Download SQL Server 2000 SP3a or MSDE 2000 SP2.
Install the following SQL Server 2000 Security Tools:
SQL Scan
SQL Check
SQL Critical Update
These tools allow you to scan instances of SQL Server 2000 or MSDE 2000 on your corporate network, detect security vulnerabilities, check a single machine, and apply security update MS02-061 to any vulnerable system.
Slammer Work
Get Inside
Slammer masquerades as a single UDP packet, one that would normally be a harmless request to find a specific database service. The first byte in the string - 04 - tells SQL Server that the data following it is the name of the online database being sought. Microsoft's tech specs dictate that this name be at most 16 bytes long and end in a telltale 00. But in the Slammer packet, the bytes run on, craftily coded so there is no 00 among them. As a result, the SQL software pastes the whole thing into memory.
Reprogram the Machine
The initial string of 01 characters spills past the 128 bytes of memory reserved for the SQL Server request and into the computer's stack next door. "Stack" is programmer-speak for an orderly list of information the computer shuffles to remind itself what to do next, like tidy paperwork on a desk. The first thing the computer does after opening Slammer's too-long UDP "request" is overwritten its own stack with new instructions that Slammer has disguised as a routine query. The computer reprograms itself without realizing it.
Choose Victims at Random
Slammer generates a random IP address, targeting another computer that could be anywhere on the Internet. To randomize, Slammer deploys a time-honored programmer's trick: It looks up the number of milliseconds that have elapsed on the CPU's system clock since it was booted and interprets the number as an IP address.
Replicate
The envelope is addressed, now it just needs to be stuffed. Slammer points to its own code as the data to send. The infected computer writes out a new copy of the worm and licks the UDP stamp.
Repeat
After sending off the first tainted packet, Slammer loops around immediately to send another to a different computer. It doesn't waste a single millisecond. Instead of making another call to the system clock to get the time, it just shuffles the bits of the IP address already in memory to create a new one. Slammer's one bug is buried here: The reshuffling leaves a few digits in the address unchanged. It hardly matters, though, since the computer is now spewing packets as fast as its network cable can carry them away. A home PC could cram a couple hundred copies onto its broadband link every second. Corporate data centers became nasty breeding grounds, launching tens of thousands per second. Slammer commandeered just 75,000 SQL machines. But because it replicated so fast, the worm was able to take down millions more, kicking them offline with a flood of meaningless traffic.