Home page logo

fulldisclosure logo 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

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:

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.

- --
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]