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 for Android: free password hash cracker in your pocket

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

Message-ID: <3E430C24.4020300@thievco.com>
From: BlueBoar at thievco.com (Blue Boar)
Subject: SQL Slammer - lessons learned

Ron DuFresne wrote:
> 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.

Depends on the resolver.  I just did some tests from Windows XPSP1 while 
running Ethereal.  If you use the Windows nslookup, it does indeed use a 
different source port for each request.  However, if you try it from the 
cmd prompt with ping, or from a browser (both of which I presume use the 
lookup calls from wsock32.dll) then it does not change source ports.  In 
fact, it used the same source port to try both (fake) DNS hosts I 
configured.  It used the same source port half a minute later when I tried 
again.

The overall point being that if you start blocking arbitrary ports, you 
break things in interesting ways.

						BB