[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Sarge, Bind9 (9.2.4-1sarge3) and DNS cache poisoning

Florian Weimer (fw@deneb.enyo.de) wrote on 20 July 2008 22:07:
 >* Vincent Deffontaines:
 >> If you run a Netfilter NAT firewall, you can use the source port NAT
 >> randomization feature of Netfilter. This feature is available in Linux
 >> vanilla kernel since
 >Thanks, very interesting.  This seems to trivially leak ten bits from
 >the net_random PRNG per newly NATted connection (perhaps more if you do
 >proper cryptanalysis).  net_random is linear and has only got 96 bits of
 >internal state, so after just 10 packets, you should be able to predict
 >the next source port choices with high accuracy (at least on a
 >relatively idle single-processor system).
 >Note that using --random with a patched resolver (one that uses stronger
 >random numbers for source ports) makes it vulnerable again.  By default,
 >Netfilter tries to preserve source ports, so its NAT does not destroy
 >the effort put into BIND et al.

Really? This post says the kernel randomization is good...

Riad S. Wahby (rsw@jfet.org) wrote on 11 July 2008 13:04:
 >Good point.  When collisions occur, as Thomas and I have pointed out,
 >the behavior of the NAT implementation is going to be crucial.
 >In the case of linux netfilter NATs, a quick look at the code reveals
 >that when netfilter selects a source port it does so with the
 >net_random() function call, which is #define'd (in include/linux/net.h)
 >as random32().  random32() comes from the kernel's lib/random32.c, and
 >according to the file header:
 >  This is a maximally equidistributed combined Tausworthe generator
 >  based on code from GNU Scientific Library 1.5 (30 Jun 2004)
 >   x_n = (s1_n ^ s2_n ^ s3_n)
 >   s1_{n+1} = (((s1_n & 4294967294) <<12) ^ (((s1_n <<13) ^ s1_n) >>19))
 >   s2_{n+1} = (((s2_n & 4294967288) << 4) ^ (((s2_n << 2) ^ s2_n) >>25))
 >   s3_{n+1} = (((s3_n & 4294967280) <<17) ^ (((s3_n << 3) ^ s3_n) >>11))
 >Even if this random number generator is prone to sequence prediction
 >attacks, Mallory does not know when the NAT is rewriting Alice's port
 >selection.  Beyond that, our scenario requires that there are collisions
 >happening, meaning that NAT's RNG state is being advanced by an unknown
 >number of other machines.  This mixing of Alice's random source ports
 >with Trent's random source ports and Carol's colliding source ports
 >would seem to make exploitation impractical even in the case that
 >Trent's RNG is weak against sequence prediction.

Reply to: