(January 29, 2003) - A pesky worm targeted servers worldwide recently: could it have been prevented? Well, to begin with, this problem was discovered and a fix posted several months ago (on July 24, 2002) at this location: www.microsoft.com/technet/treeview/default.asp?url=/technet/secur ity/bulletin/MS02-039.asp>

A complete (highly technical) description of the problem is here:http://support.microsoft.com/default.aspx?scid=kb;[LN];323875.

In a nutshell, though (and for the less technically inclined amongst us), the attack involves sending a specially crafted packet to the SQL Server Resolution Service on port 1434. This packet is larger than the kinds of packets that SQL Server expects to receive on this port (100 *bytes instead of 25, for example). What happens in cases like this is that the excess bytes (75 bytes in the case of the example above) get pushed right over the boundary of the receiving memory buffer into system memory.

If you can put code that you want to have executed into those excess bytes, it might get run - as it apparently does in the case of this bug. It is a class of attack known as a "buffer overrun attack" - because it works by overrunning a given piece of memory (the "buffer") with more data than is expected (the larger-than-expected packet). The virus is in the excess bytes and gets run when it finds itself pushed into system memory.

Thankfully, all this virus does is replicate itself. The only instructions in the virus are those required to generate random IP addresses and send a destructive packet to port 1434 on them - hoping to get lucky by finding additional SQL Servers where it can be reborn. The Denial-of-Service that wound up plaguing the Internet was caused by the fact that the viruses all spin really quickly, sending lots and lots of packets to lots and lots of machines on the Internet. So, there was a lot of extra traffic on the Internet, and SQL Servers that became infected were slowed down by the extra processing involved in having these viruses generating and sending all of these extra packets.

Here is a nice, medium-level explanation of the above:

www.canada-av.com/sensible/home.nsf/b420c8d799b6e7cb852568c900171 ffd/7afb5a9c7a0dc63f85256cb9005be24a?OpenDocument.