Date:         Wed, 12 Jan 2000 08:28:07 -0000
From: "D. J. Bernstein" <djb@CR.YP.TO>
Subject:      Blinding BIND to a moving domain
To: BUGTRAQ@SECURITYFOCUS.COM

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