full-disclosure - Re: DNS and NAT (was: DNS and CheckPoint)

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] [day] [month] [year] [list]

Message-ID: <487E7372.4040603@sensepost.com>
Date: Thu, 17 Jul 2008 00:17:22 +0200
From: Marco Slaviero <marco@...sepost.com>
To: Valdis.Kletnieks@...edu
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: DNS and NAT (was: DNS and CheckPoint)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Valdis.Kletnieks@...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/