full-disclosure - Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sun, 13 Jul 2008 19:26:36 -0500
From: "eugaaa@...il.com" <eugaaa@...il.com>
To: coderman <coderman@...il.com>
Cc: full-disclosure@...ts.grok.org.uk,
	Paul Schmehl <pschmehl_lists_nada@...rr.com>
Subject: Re: DNS Cache Dan Kamikaze (Actual Exploit
	Discussion)

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@...il.com> wrote:
> On Sun, Jul 13, 2008 at 2:27 PM, eugaaa@...il.com <eugaaa@...il.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/