Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion)

["eugaaa () gmail com" <eugaaa () gmail com>]

What you wrote here 'http://wari.mckay.com/~rm/dns_theroy.txt' does
not make sense. To send a legitimate ICMP dest unreachable you would
need to send back the 20 byte IP header and the first 4 bytes of the
UDP header. That means src_addr, dst_addr, src_port, dst_port. So in
reality, you've taken a dns problem and made it into a spoofing
problem. There are also a lot of questions your theory needs to
address:

Why flood with dest unreachables when your goal is to answer before
the nameserver? Do you even know what would happen if a valid query
response came in after a dest unreachable? Did you know that many
people use their gateways to forward DNS queries (meaning you would
have to account for NAT addresses as well as state)?

All that aside, from what I have seen it has to do with DNS transaction ID's.

"Today, there still exist problems. BIND 8 and BIND 9 both have
problems generating truly random transaction IDs. A transaction ID is
a 16 bit number (i.e. 1-65536) that identifies a single DNS
transaction. BIND 9 uses the operating system's /dev/random device, so
the randomness is much better than existed in version 8"

Meaning it is a remote timing based attack because of the
pseudo-random nature of the transaction ID's. What amazes me is that
this problem apparently exist in so many vendors?

Does anyone have any insight as to why?

On 7/13/08, coderman <coderman () gmail com> wrote:
> On Sun, Jul 13, 2008 at 2:27 PM, eugaaa () gmail com <eugaaa () gmail com> wrote:
> > ...
> > So on that note I'll be more direct. Has anyone actually preemptively
> > written any code or reversed this issue on their own? Or just, you
> > know, attempted to understand the vulnerability in detail instead of
> > relying on these intentionally vague advisories (dan)?
>
> my money is currently on ICMP port unreachable combined with the
> predictable ports to trick vulnerable resolvers into thinking the
> configured nameservers are offline:
>
> http://wari.mckay.com/~rm/dns_theroy.txt
>
> you could fix this via the method described, and not imply that the
> ICMP was part of the vector.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/