COMMAND

    BIND

SYSTEMS AFFECTED

    BIND 8.2.2

PROBLEM

    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:

        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.

SOLUTION

    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?