Bugtraq mailing list archives
Re: Blinding BIND to a moving domain
From: ken () THECHAIN COM (Ken Gourlay)
Date: Wed, 12 Jan 2000 16:03:33 -0500
Dan, Correct me if I'm wrong, but if I understand the problem here correctly, this bug can be avoided if at least one of the new victim.dom nameservers are not in the victim.dom domain but rather in a domain with uncached or unchanged nameservers. This way the caching server would retain correct information for one of the nameservers, resolve to the server, and get valid addresses for any servers in the victim.dom domain (and at the same time it could (would?) pick up authoritative NS records for the domain, entirely replacing the old info in the cache). Of course, moving a nameserver out of the domain might be as much trouble as moving the domain to begin with... oh well. Plan ahead so you can wait until the cache records time out, right? My take on this is that it sounds like the root of the moving domain problem is not in the seemingly irrelevent programming decision as much as it is in the choice of who is the authority on the NS records. (IMO at least) the .dom servers hold the authority for the NS records, not the victim.dom nameservers. If the lookup request to the .dom servers returned authoritative NS records for the victim.dom domain (below) then the obsolete records in the cache would be replaced by these and valid lookups could be performed (initially using the new, unauthoritative A records from the .dom server). victim.dom 259200 NS ns1.victim.dom victim.dom 259200 NS ns2.victim.dom Of course, this can't happen because the whole DNS system isn't set up with authority for the NS records in the "right" place (or even the ability to have it set up that way). Bummer. -- Ken Gourlay "D. J. Bernstein" wrote:
Summary: If you're running BIND 8.2.2, and you have the victim.dom name servers in your cache, and victim.dom changes its server names, then any user who can make recursive queries through your cache can break your victim.dom lookups until the old records time out. The complete attack is one brief burst of legitimate packets. This is, of course, not as disastrous as BIND's next buffer overflow, but it's still an interesting example of how an attacker can use BIND's bogus ``credibility'' mechanism to exacerbate the effects of a seemingly minor bug and a seemingly irrelevant programming decision. There's also a race condition here that will allow a similar attack, at the expense of a low-bandwidth flood, when victim.dom isn't changing its server names. I'll leave this as an exercise for the reader. Details: Let's say the old victim.dom name servers were sun37.victim.dom (1.2.3.4) and pc5.victim.dom (5.6.7.8). The new servers are ns1.victim.dom (1.2.3.5) and ns2.victim.dom (5.6.7.9). After setting up the new servers, the administrator tells the .dom registrar to change the NS records. Of course, he leaves the old servers running for a while. Eventually the .dom registrar changes the victim.dom information: victim.dom 259200 NS ns1.victim.dom victim.dom 259200 NS ns2.victim.dom ns1.victim.dom 259200 A 1.2.3.5 ns2.victim.dom 259200 A 5.6.7.9 Meanwhile, your cache still has the old information: victim.dom 258437 NS sun37.victim.dom victim.dom 258437 NS pc5.victim.dom sun37.victim.dom 258437 A 1.2.3.4 pc5.victim.dom 258437 A 5.6.7.8 Now the attacker swings into action. All he has to do is ask your cache for the addresses of sun37.victim.dom and pc5.victim.dom a few hundred times. BIND assigns a ``credibility'' level of ``additional records'' to these addresses, and reduces the TTLs by 5% for each query: victim.dom 258435 NS sun37.victim.dom victim.dom 258435 NS pc5.victim.dom sun37.victim.dom 5 A 1.2.3.4 pc5.victim.dom 5 A 5.6.7.8 A few seconds later, the address records expire, leaving only the NS records, which will remain in your cache for a few days. An innocent user now asks your cache for the address of blah.victim.dom. Your cache sees that it can get the answer from the .victim.dom servers, sun37.victim.dom and pc5.victim.dom. But, oops, the addresses aren't available; your cache has to look them up. The seemingly minor bug is that BIND drops the blah.victim.dom query at this point. It hopes to have the sun37 and pc5 information cached by the time the user's stub resolver retries the query, so that it can resolve blah.victim.dom successfully. How, then, does your cache find the addresses of sun37.victim.dom and pc5.victim.dom? It could get the answer from the .victim.dom servers... Fortunately, the cache is smart enough to recognize this loop; it ignores the useless NS records and falls back to the .dom servers. The seemingly irrelevant programming decision is that BIND doesn't actually discard the useless NS records from the cache. It simply ignores them for the moment. The .dom servers provide a ``non-authoritative'' response with the new NS records and A records: victim.dom 259200 NS ns1.victim.dom victim.dom 259200 NS ns2.victim.dom ns1.victim.dom 259200 A 1.2.3.5 ns2.victim.dom 259200 A 5.6.7.9 BIND assigns a ``credibility'' level of ``authority records from a non-authoritative response'' to the new NS records, and ``authority records from an authoritative response'' to the useless NS records in its cache, so it discards the new NS records. It sticks to the old NS records until they time out. Meanwhile, it doesn't have the sun37 and pc5 addresses that it needs. ---Dan
Current thread:
- Re: ICQ Buffer Overflow Exploit, (continued)
- Re: ICQ Buffer Overflow Exploit Tom Schumm (Jan 14)
- Re: ICQ Buffer Overflow Exploit Simon Steed (Jan 13)
- Anyone can take over virtually any domain on the net... Thomas Reinke (Jan 11)
- Re: Anyone can take over virtually any domain on the net... Jon Lewis (Jan 13)
- Re: Anyone can take over virtually any domain on the net... Jeffrey Paul (Jan 13)
- Re: Anyone can take over virtually any domain on the net... Chris Adams (Jan 13)
- Re: Anyone can take over virtually any domain on the net... Shafik Yaghmour (Jan 13)
- Re: Anyone can take over virtually any domain on the net... Nick Lamb (Jan 15)
- Re: Anyone can take over virtually any domain on the net... Kurt Seifried (Jan 13)
- Blinding BIND to a moving domain D. J. Bernstein (Jan 12)
- Re: Blinding BIND to a moving domain Ken Gourlay (Jan 12)
- CyberCash MCK 3.2.0.4: Large /tmp hole Sheldon Young (Jan 12)
- Administrivia: ORBS Elias Levy (Jan 12)
- WebSitePro/2.3.18 is revealing Webdirectories Lark Lizerman (Jan 12)
- Re: Hotmail security hole - injecting JavaScript using <IMG Grahame Bowland (Jan 05)
- Re: Hotmail security hole - injecting JavaScript using <IMG Dustin Miller (Jan 05)