On Thu, Oct 14, 2010 at 03:20:06PM -0600, Theo de Raadt wrote: > > On Thu, Oct 14, 2010 at 11:57 AM, Mike Belopuhov <[email protected]> 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.
These issues have been fixed. Thanks for the reports. Note that this code is still very experimental and should be used with care. Lots of things are still missing, but I wanted to get something functional enough to test and settle the API. Eric.
