I would like to revise my previous statement.

W32/SQLSlammer, as its being called now, does not act like SQL-Spida,
and the mitigators to prevent SQL-Spida are not necessarily effective in
preventing SQLSlammer.

SQLSlammer is delivered entirely in the single connection, 367 bytes of
attack code. It appears to be entirely memory resident, iows, it won't
drop anything. It does not appear to take advantage of weak passwords or
any stored procedures, it simply overflows the buffer and executes.
Also, SQL-Spida attacked 1433, whereas this attacks UDP1434.

If this attack is also employing the SQL Ping bounce described by David
Litchfield last July, then this could account for the amount of
bandwidth being consumed by this. Look in the NTBugtraq archives for
David's email.

There is some discussion occurring that ISPs are blocking this traffic,
so we should see recovery relatively quickly.

So far there have been no reports of SQL 7 or lower being affected.

More as its available.

Cheers,
Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor

oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Delivery co-sponsored by TruSecure Corporation
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
TICSA - Anniversary Special - Limited Time

Become TICSA certified for just $221.25 US when you register before 3/31/03
with PROMO "TS0103" at www.2test.com. NO membership fees, certification
good for 2 years. Price for international delivery just $296.25 US, with
this offer. Offer cannot be combined with any other special and expires
3/31/03. Visit www.trusecure.com/ticsa for full details.

oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]