Re: Sarge, Bind9 (9.2.4-1sarge3) and DNS cache poisoning
* Carlos Carvalho: > >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... It applies to the configuration without --random. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sarge, Bind9 (9.2.4-1sarge3) and DNS cache poisoning
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]
Re: Sarge, Bind9 (9.2.4-1sarge3) and DNS cache poisoning
* Vincent Deffontaines: > One solution is to let another device do the port randomization, to > protect your DNS clients. This is correct, but the device needs to know about the DNS protocol, so that it ties QNAME/QCLASS/QTYPE and transaction ID and source port to a particular request. > 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). For stub resolvers, this seems to be less relevant, but for caching resolvers, it's a problem because the source port information trivially leaks to the attacker. 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sarge, Bind9 (9.2.4-1sarge3) and DNS cache poisoning
On Sun, 2008-07-20 at 14:04, Florian Weimer wrote: > * John Elliot: > > Hi, We have a couple of Sarge servers running bind9(9.2.4-1sarge3) > > that appear to be vulnerable to the DNS cache poisoning issue(Looks > > like port randomization was only introduced in bind9.3?) - As the > > servers cannot be upgraded at this time to etch, what is the > > recommended course of action? Backports and upgrade to 9.3? > Install one or more etch boxes, put BIND 9 onto it, and configure the > sarge machines to use them as forwarders. This is sufficient if the > network between them is trusted. You could also forward requests to > your ISP's resolvers (subject to the same constraint). Simpler and more secure (and easier) solution is the installation of the djbdns. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sarge, Bind9 (9.2.4-1sarge3) and DNS cache poisoning
* John Elliot: > Hi, We have a couple of Sarge servers running bind9(9.2.4-1sarge3) > that appear to be vulnerable to the DNS cache poisoning issue(Looks > like port randomization was only introduced in bind9.3?) - As the > servers cannot be upgraded at this time to etch, what is the > recommended course of action? Backports and upgrade to 9.3? Install one or more etch boxes, put BIND 9 onto it, and configure the sarge machines to use them as forwarders. This is sufficient if the network between them is trusted. You could also forward requests to your ISP's resolvers (subject to the same constraint). I could provide you with an untested 9.3 backport for sarge (or you could compile one yourself). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sarge, Bind9 (9.2.4-1sarge3) and DNS cache poisoning
John Elliot a écrit : Hi, We have a couple of Sarge servers running bind9(9.2.4-1sarge3) that appear to be vulnerable to the DNS cache poisoning issue(Looks like port randomization was only introduced in bind9.3?) - As the servers cannot be upgraded at this time to etch, what is the recommended course of action? Backports and upgrade to 9.3? Greetings, One solution is to let another device do the port randomization, to protect your DNS clients. 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 See http://software.inl.fr//trac/wiki/contribs/RandomSkype Vincent Deffontaines -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Sarge, Bind9 (9.2.4-1sarge3) and DNS cache poisoning
Hi, We have a couple of Sarge servers running bind9(9.2.4-1sarge3) that appear to be vulnerable to the DNS cache poisoning issue(Looks like port randomization was only introduced in bind9.3?) - As the servers cannot be upgraded at this time to etch, what is the recommended course of action? Backports and upgrade to 9.3? _ Meet singles near you. Try ninemsn dating now! http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating%2Eninemsn%2Ecom%2Eau%2Fchannel%2Findex%2Easpx%3Ftrackingid%3D1046247&_t=773166080&_r=WL_TAGLINE&_m=EXT
