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 23:30:21 -0500
From: "eugaaa@...il.com" <eugaaa@...il.com>
To: "Paul Schmehl" <pschmehl_lists_nada@...rr.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: DNS Cache Dan Kamikaze (Actual Exploit
	Discussion)

Yes, the issue was side tracked a bit. And I'm sure I am
misunderstanding the issue at this point (but I'm also reading
accounts of multiple vulnerabilities so that cannot be avoided)

But normally in DNS operations, slaves and their master are placed in
an authority encapsulated domain for transfers. IE. the slaves will
only axfr zones from the master.

And in the case of recursion, assuming the nameservers are recursive
it will hit the root and fly downward looking for the zone's
authoritative nameserver. The exploitation must happen here - a way to
become the authoritative nameserver. Am I wrong? Because it seems like
the transferring of zones/records is accounted for. Are we
manipulating root hints now? Any input is appreciated.

On 7/13/08, Paul Schmehl <pschmehl_lists@...rr.com> wrote:
> --On July 13, 2008 9:44:19 PM -0500 eugaaa@...il.com wrote:
>
>> If the nameserver is "down" most likely the resolver is going to try a
>> different one. Meaning you're back to square one. Which is why I asked
>> what happens if the resolver recv's a response after it's been told
>> the nameserver is down. In any case, I'm not even sure how resolvers
>> handle dest unreachables. And again, I think that avenue is moot.
>>
>> As for your question about theory versus practicality. 2^16 seems
>> possible. This exact same problem exist with ASLR implementations as
>> well as stack protection mechanisms (canary values etc). I think even
>> vista's current address space randomization is 16-bits. However with
>> these DNS transaction ID's you're not looking at a random number. It's
>> scope is limited because you've seen the transaction ID's of each
>> request you've made. IE my first request was 125, my second was 133,
>> etc. Meaning you pick a number higher up (180) and try to win the
>> race.
>>
>
> I think you are fundamentally misunderstanding the problem.  The
> vulnerability we're discussing allows you to *poison* a nameserver's
> cache.  You *want* the nameserver to answer.  You don't want to answer on
> its behalf.  You want it to answer - incorrectly - so that users are
> fooled into thinking they've been taken to the real site when in fact they
> been taken to a "mirror" of the real site, specially prepared for whatever
> nefarious purpose you have in mind.
>
> Paul Schmehl
> If it isn't already obvious,
> my opinions are my own and not
> those of my employer.
>

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