[unisog] earlier report of SQL slapper worm

H. Morrow Long morrow.long at yale.edu
Sat Feb 1 18:04:14 GMT 2003

Valdis.Kletnieks at vt.edu wrote:
> The point was that the lack of randomness was found in TCP stacks that had
> supposedly been intentionally hardened to create unpredictable ISNs.  We're
> talking here about code from major vendors who were motivated to do it right.
> It's not at all surprising that J Random Hacker does an even worse job.

Valdis (and Robert Dormer) - I agree that that is a very good point.

There is also a good analysis of the worm (which includes a critique of the
random IP address number generation flaws in it) out.  I'm forwarding this
announcement of the analysis on the speed and spread of the worm (forwarded
from SECURITY at LISTSERV.EDUCAUSE.EDU) posted to the NANOG (North American
Network Operators Group) list.

Apparently the worm attained a highly successful penetration rate in its first
10 minutes after 12:30am, making for a speed and spread which outperformed the
prediction of the 'Andy Warhol worm' USENIX Security 02 paper (2002 by Nicholas
Weaver, Vern Paxton and others involved in the analysis of the Sapphire/Slammer
worm and available at: http://www.cs.berkeley.edu/~nweaver/cdc.web/).


 >> -----Original Message-----
 >> From: vern at ee.lbl.gov
 >> Date: Fri, 31 Jan 2003 17:13:14
 >> To:nanog at merit.edu
 >> Subject: The Spread of the Sapphire/Slammer SQL Worm
 >> We have completed our preliminary analysis of the spread of the
 >> Sapphire/Slammer SQL worm.  This worm required roughly 10 minutes to
 >> spread worldwide making it by far the fastest worm to date.  In the
 >> early stages the worm was doubling in size every 8.5 seconds.  At its
 >> peak, achieved approximately 3 minutes after it was released, Sapphire
 >> scanned the net at over 55 million IP addresses per second.  It
 >> infected at least 75,000 victims and probably considerably more.
 >> This remarkable speed, nearly two orders of magnitude faster than Code
 >> Red, was the result of a bandwidth-limited scanner.  Since Sapphire
 >> didn't need to wait for responses, each copy could scan at the maximum
 >> rate that the processor and network bandwidth could support.
 >> There were also two noteworthy bugs in the pseudo-random number
 >> generator which complicated our analysis and limited our ability to
 >> estimate the total infection but did not slow the spread of the worm.
 >> The full analysis is available at
 >> http://www.caida.org/analysis/security/sapphire/
 >> http://www.silicondefense.com/sapphire/
 >> http://www.cs.berkeley.edu/~nweaver/sapphire/
 >> David Moore, CAIDA & UCSD CSE
 >> Vern Paxson, ICIR & LBNL
 >> Stefan Savage, UCSD CSE
 >> Colleen Shannon, CAIDA
 >> Stuart Staniford, Silicon Defense
 >> Nicholas Weaver, Silicon Defense and UC Berkeley EECS

More information about the unisog mailing list