Florian Weimer ([EMAIL PROTECTED]) 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 2.6.21.1
>
>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 ([EMAIL PROTECTED]) 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))
>(etc)
>*/
>
>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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
