full-disclosure - SQL Slammer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.GSO.4.43.0302061842100.27886-100000@tundra.winternet.com>
From: dufresne at winternet.com (Ron DuFresne)
Subject: SQL Slammer - lessons learned

On Thu, 6 Feb 2003, Blue Boar wrote:

> Ron DuFresne wrote:
> >>port 1434 on a client (so blocking replies)
> > of course the client will reissue the request on aonther port and  get the
> > info required.  No harm done.
>
> Maybe for a completely different lookup call, it will.  Meanwhile, the
> blocked lookup comes back as no response, which will be interepreted as no
> such name.

Perhaps I'm wrong and will be corrected, but nslookup and dig and the
various other tools retry after a short timeout period, and do so on
different ports then the first timeout request was made.<?>  If I'm
reading this correctly, then the significance of a dropped packet in a
request is minimal.

Thanks,

Ron DuFresne
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
	***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D.  Just don't touch anything.