> On Thu, Oct 14, 2010 at 11:57 AM, Mike Belopuhov <m...@crypt.org.ru> wrote: > > this dns code has a serious flaw. you use arc4random to allocate request > > IDs. this is a bad decision, as you actually want a non-repeating > property. > > Why? Each query transmission uses a newly allocated socket with a > unique (random) source port address. The same txid might be used by > multiple concurrent queries, but forgeries have to match both the txid > and the source port so there's no risk of colliding attacks.
Here's a random sequence that arc4random can legitimately put out: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 There is is random. It could. Saying that DNS doesn't care is irresposible. It was never specifically designed to not care, and this is much more likely than with other protocols since it's id space is only 16 bits. Protecting this only with the < 16 bit socket port number is irresponsible. Protecting it with an additional 16 bits -- essentially for free -- which do not collide is the responsible thing to do. > Also, that code doesn't seem to check the source IP address of the > response DNS packet. An easy fix (e.g., what djbdns does) is use > connect(2) on the UDP socket so the kernel discards packets from bad > source IPs/ports, and then just use send(2) and recv(2). Right.
