Full Disclosure mailing list archives
Re: DNS and NAT (was: DNS and CheckPoint)
From: Marco Slaviero <marco () sensepost com>
Date: Thu, 17 Jul 2008 00:17:22 +0200
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Valdis.Kletnieks () vt edu wrote: | On Fri, 11 Jul 2008 11:01:33 EDT, Thomas Cross said: | |> Thanks for testing this. A number of other readers wrote me privately |> confirming your result with linux ipchains. I'm not sure what ipchains does |> when it encounters a collision, but in general I think this is a good |> strategy. You'd have to have many thousands of simultaneous UDP |> transactions in order for randomly selected source ports to be colliding |> frequently enough for it to present a substantial problem. | | Birthday paradox strikes again. | | With 64K source ports, you'll have collisions over 1% of the time at only 1024 | in use. With 8K in use, you're hitting collisions 12% of the time. Which, if my dodgy stats are correct, is the probability of collision if we choose a particular source port to watch for collisions. If we're not fussy about particular ports but are happy with any collisions, then the common birthday attack shows that when approximately 301 packets with random ports require NATing there will be a _50%_ chance that at least two of those ports collide: sqrt(2*2^16*ln(1/.5)) Ruby for fun (cut/past into irb): a=[];1.upto(301){|i| n=(rand(2**16).to_i); puts "Collide" if a.include?(n); a[i]=n; } Of course, whether this becomes meaningful in the context of the DNS vuln is a little less clear-cut; it would appear from all the fuss that the issue(s) tend to deeper problems than stats fiddling, and the iptables example would require more that just generating an internal source-port collision to exploit. As Riad pointed out, the amount of unpredictability in the arriving packets combined with the RNG would probably render the birthday attack much less effective without deriving further information from the NAT (one way to derive info might be with an attacker-initiated stream of lookups to the attackers DNS combined with knowledge of the PNRG implementation to guess PNRG state). I suspect at this point the chances are pretty slim of this occurring, as Rias also stated. But the collision angle was an interesting addition to this kerfuffle. - -- marco -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREDAAYFAkh+cs8ACgkQiAIcbqYz6hlguACgjj4LjnkpNgkRXzAJ+gtk7+Q9 4+IAniEFqgWd4RdW5nK2kim3jb8bGXDc =oroB -----END PGP SIGNATURE----- _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- DNS and NAT (was: DNS and CheckPoint) Thomas Cross (Jul 10)
- Re: DNS and NAT (was: DNS and CheckPoint) Riad S. Wahby (Jul 10)
- Re: DNS and NAT (was: DNS and CheckPoint) Thomas Cross (Jul 11)
- Re: DNS and NAT (was: DNS and CheckPoint) Valdis . Kletnieks (Jul 11)
- Re: DNS and NAT (was: DNS and CheckPoint) Riad S. Wahby (Jul 11)
- Re: DNS and NAT (was: DNS and CheckPoint) Marco Slaviero (Jul 16)
- Re: DNS and NAT (was: DNS and CheckPoint) Thomas Cross (Jul 11)
- Re: DNS and NAT (was: DNS and CheckPoint) Riad S. Wahby (Jul 10)
- Re: DNS and NAT (was: DNS and CheckPoint) Ryan McBride (Jul 16)
- <Possible follow-ups>
- Re: DNS and NAT (was: DNS and CheckPoint) Elazar Broad (Jul 11)
- Re: DNS and NAT (was: DNS and CheckPoint) Thomas Cross (Jul 14)