Editing SQL Slammer (section)

==Technical details==
The worm was based on proof of concept code demonstrated at the [[Black Hat Briefings]] by [[David Litchfield]], who had initially discovered the buffer overflow vulnerability that the worm exploited.<ref>{{cite news|first=John |last=Leyden|url=https://www.theregister.co.uk/2003/02/06/slammer_why_security_benefits/ |title=Slammer: Why security benefits from proof of concept code |publisher=Register | date=6 February 2003 |access-date=2008-11-29}}</ref> It is a small piece of code that does little other than generate random IP addresses and send itself out to those addresses. If a selected address happens to belong to a host that is running an unpatched copy of [[Microsoft SQL Server]] Resolution Service listening on UDP port 1434, the host immediately becomes infected and begins spraying the Internet with more copies of the worm program.

Home [[Personal Computer|PC]]s are generally not vulnerable to this worm unless they have MSDE installed. The worm is so small that it does not contain code to write itself to disk, so it only stays in memory, and it is easy to remove. For example, Symantec provides a free of charge removal utility, or it can even be removed by restarting SQL Server (although the machine would likely be reinfected immediately).

The worm was made possible by a [[software security vulnerability]] in SQL Server first reported by Microsoft on 24 July 2002. A patch had been available from Microsoft for six months prior to the worm's launch, but many installations had not been patched – including many at Microsoft.<ref>{{cite magazine|url=https://www.wired.com/2003/01/microsoft-attacked-by-worm-too/ |title=Microsoft Attacked By Worm, Too|magazine=Wired}}</ref>

The worm began to be noticed early on 25 January 2003{{efn|Public disclosure began with Michael Bacarella posting a message to the [[Bugtraq]] security mailing list entitled "MS SQL WORM IS DESTROYING INTERNET BLOCK PORT 1434!"<ref>{{cite web|first=Michael |last=Bacarella |url=http://seclists.org/bugtraq/2003/Jan/221 |title=MS SQL WORM IS DESTROYING INTERNET BLOCK PORT 1434! |publisher=Bugtraq |date=25 January 2003 |access-date=2012-11-29}}</ref> at 07:11:41 UTC on 25 January 2003. Similar reports were posted by Robert Boyle at 08:35 UTC<ref>{{cite web |first=Robert |last=Boyle |url=http://archives.neohapsis.com/archives/ntbugtraq/2003-q1/0011.html |title=Peace of Mind Through Integrity and Insight |publisher=Neohapsis Archives |date=25 January 2003 |access-date=2008-11-29 |archive-url=https://web.archive.org/web/20090219072838/http://archives.neohapsis.com/archives/ntbugtraq/2003-q1/0011.html |archive-date=19 February 2009 |df=dmy-all }}</ref> and Ben Koshy at 10:28 UTC<ref>{{cite web |first=Ben |last=Koshy |url=http://archives.neohapsis.com/archives/ntbugtraq/2003-q1/0010.html |title=Peace of Mind Through Integrity and Insight |publisher=Neohapsis Archives |date=25 January 2003 |access-date=2008-11-29 |archive-url=https://web.archive.org/web/20090219072809/http://archives.neohapsis.com/archives/ntbugtraq/2003-q1/0010.html |archive-date=19 February 2009 |df=dmy-all }}</ref> An early analysis released by Symantec is timestamped 07:45 GMT.<ref>{{cite web|url=http://securityresponse.symantec.com/avcenter/Analysis-SQLExp.pdf |archive-url=https://web.archive.org/web/20030307233701/http://securityresponse.symantec.com/avcenter/Analysis-SQLExp.pdf |url-status=dead |archive-date=7 March 2003 |publisher=DeepSight™ Threat Management System Threat Analysis |title=SQLExp SQL Server Worm Analysis |date=Jan 28, 2003}}</ref>}} as it slowed systems worldwide. The slowdown was caused by the collapse of numerous [[router (computing)|router]]s under the burden of extremely high bombardment traffic from infected servers. Normally, when traffic is too high for routers to handle, the routers are supposed to delay or temporarily stop network traffic. Instead, some routers ''crashed'' (became unusable), and the "neighbour" routers would notice that these routers had stopped and should not be contacted (aka "removed from the [[routing table]]"). Routers started sending notices to this effect to other routers they knew about. The flood of routing table update notices caused some additional routers to fail, compounding the problem. Eventually the crashed routers' maintainers restarted them, causing them to announce their status, leading to another wave of routing table updates. Soon a significant portion of Internet bandwidth was consumed by routers communicating with each other to update their routing tables, and ordinary data traffic slowed or in some cases stopped altogether. Because the SQL Slammer worm was so small in size, sometimes it was able to get through when legitimate traffic was not.

Two key aspects contributed to SQL Slammer's rapid propagation. The worm infected new hosts over the [[Session (computer science)|sessionless]] [[User Datagram Protocol|UDP]] protocol, and the entire worm (only 376 bytes) fits inside a single packet.<ref>{{cite web|author=Moore, David|title=The Spread of the Sapphire/Slammer Worm|work=CAIDA (Cooperative Association for Internet Data Analysis)|url=https://www.caida.org/catalog/papers/2003_sapphire/|display-authors=etal}}</ref><ref>{{cite book|author1=Serazzi, Giuseppe |author2=Zanero, Stefano|chapter=Computer Virus Propagation Models|editor1=Calzarossa, Maria Carla |editor2=Gelenbe, Erol|title=Performance Tools and Applications to Networked Systems|series=Lecture Notes in Computer Science|volume=2965|year=2004|pages=26–50|chapter-url=http://home.deib.polimi.it/zanero/papers/zanero-serazzi-virus.pdf}}</ref> As a result, each infected host could simply "fire and forget" packets as rapidly as possible.