My analysis of the problem is now that the exploitation happens when a recursive server goes looking for a record, and in doing so opens connections to query each nameserver it finds along the path to the authoritative namserver.
me -> my_dns(recursive) my_dns -> root my_dns -> almost_auth my_dns -> auth_dns During this period, an attacker floods the query port (or ports) of my_dns with a valid response for the domain (this is made possible by weak transaction ID's in most nameservers and the pseudo-randomness of the query port) and in doing so manipulates the cache. There were so many avenues of exploitation for this I actually overlooked the glaringly obvious one. On 7/13/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > 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 <[EMAIL PROTECTED]> wrote: >> --On July 13, 2008 9:44:19 PM -0500 [EMAIL PROTECTED] 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/
