Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion)
From: "eugaaa () gmail com" <eugaaa () gmail com>
Date: Sun, 13 Jul 2008 19:26:36 -0500

What you wrote here 'http://wari.mckay.com/~rm/dns_theroy.txt&apos; 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

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:


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/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]