what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

bind15.htm

bind15.htm
Posted Jan 21, 2000
Site oliver.efri.hr

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.

tags | exploit, overflow
SHA-256 | c72ec0dd61841711d365e087961f01b3cc66fb2e349bb4274b3c897e6f364742

bind15.htm

Change Mirror Download
<!DOCTYPE HTML PUBLIC "html.dtd">
<HTML>
<BODY BGCOLOR="#000000" TEXT="#FFFFFF"><PRE>
<FONT COLOR="#CC0000">COMMAND</FONT>

BIND

<FONT COLOR="#CC0000">SYSTEMS AFFECTED</FONT>

BIND 8.2.2

<FONT COLOR="#CC0000">PROBLEM</FONT>

D. J. Bernstein found following. 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. Dan left it as an exercise for
the reader.

Here are more 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:
<FONT COLOR="#00FF00">
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
</FONT>
Meanwhile, your cache still has the old information:
<FONT COLOR="#00FF00">
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
</FONT>
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:
<FONT COLOR="#00FF00">
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
</FONT>
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:
<FONT COLOR="#00FF00">
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
</FONT>
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.

<FONT COLOR="#CC0000">SOLUTION</FONT>

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?
</PRE></BODY>
</HTML>
Login or Register to add favorites

File Archive:

June 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jun 1st
    0 Files
  • 2
    Jun 2nd
    0 Files
  • 3
    Jun 3rd
    18 Files
  • 4
    Jun 4th
    21 Files
  • 5
    Jun 5th
    0 Files
  • 6
    Jun 6th
    57 Files
  • 7
    Jun 7th
    6 Files
  • 8
    Jun 8th
    0 Files
  • 9
    Jun 9th
    0 Files
  • 10
    Jun 10th
    12 Files
  • 11
    Jun 11th
    27 Files
  • 12
    Jun 12th
    38 Files
  • 13
    Jun 13th
    16 Files
  • 14
    Jun 14th
    14 Files
  • 15
    Jun 15th
    0 Files
  • 16
    Jun 16th
    0 Files
  • 17
    Jun 17th
    16 Files
  • 18
    Jun 18th
    26 Files
  • 19
    Jun 19th
    0 Files
  • 20
    Jun 20th
    0 Files
  • 21
    Jun 21st
    0 Files
  • 22
    Jun 22nd
    0 Files
  • 23
    Jun 23rd
    0 Files
  • 24
    Jun 24th
    0 Files
  • 25
    Jun 25th
    0 Files
  • 26
    Jun 26th
    0 Files
  • 27
    Jun 27th
    0 Files
  • 28
    Jun 28th
    0 Files
  • 29
    Jun 29th
    0 Files
  • 30
    Jun 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close