COMMAND

    bind ()

SYSTEMS AFFECTED

    All versions of BIND before release 8.1.1 are vulnerable.

PROBLEM

    Several  vulnerabilities  in  the  Berkeley  Internet  Name Daemon
    (BIND) have  been fixed  in the  current version  of BIND.  One of
    those  vulnerabilities  is  now  being  exploited, a vulnerability
    that  results  in  cache  poisoning  (malicious or misleading data
    from  a  remote  name  server  is  saved  [cached] by another name
    server).

    The mapping between host names and IP addresses may be changed. As
    a  result,  attackers  can   inspect,  capture,  or  corrupt   the
    information exchanged between hosts on a network.

    This little script "bind_nuke":

        #!/bin/bash

        echo 'bind_nuke (c) Artur Skawina skawina@usa.net'

        nsupdate <<END
        update delete x.$1 A
        update add x.$1 60 IN A 3.2.3.6
        update delete x.$1 A

        END

    when executed as "bind_nuke bogus.org" on a host, that bogus.org's
    primary NS is configured to accept updates from, will cause  named
    to silently  die. Nothing  in the  logs, nothing  on the  console.
    After a number of similar  packets has been received by  named any
    subsequent attempt to  run it will  only result in  a Segmentation
    Fault.  [and there's "spoofing"...]

    The problem seems to be that bind can not handle updating the same
    RR more than  once in the  same DNS packet.   And as it  saves the
    update requests in the <zone>.log file and attempts to perform the
    updates again when restarted, the bug is triggered again...

    The bug is  present in both  bind8.1 and bind8.1.1.   With bind8.1
    one such DU packet was enough to prevent named from runing,  until
    the /var/named/pri/<zone>.log file was removed/edited.  Bind 8.1.1
    needs a few packets (but  usually <=3) before this happens  (named
    still dies after only one packet, but it is sometimes possible  to
    restart it  w/o any  immediate errors/warnings).   Credit goes  to
    Aveek Data.

SOLUTION

    Obtain and install a patch for  this problem.  Below is a  list of
    the vendors who have provided information for CERT advisory.

    Cray Research - A Silicon Graphics Company
    ===========================================
        Cray Research has determined that the version of BIND  shipped
        with  all  current  releases  of  Unicos  and  Unicos/mk   are
        susceptible to the problem described in this advisory.  We are
        currently  working  on  upgrading  our  version of BIND to the
        4.9.6 release.

    Digital Equipment Corporation
    =============================
    xref CASE ID: SSRT0494U
        At the time of writing this document, patches(binary kits) are
        in progress and final patch testing is expected to begin soon.
        Digital will provide notice of the completion/availability  of
        the patches through AES  services (DIA, DSNlink FLASH)  and be
        available from your normal Digital Support channel.

    Hewlett-Packard Company
    =======================
        HP is vulnerable. Patches in process.

    IBM Corporation
    ===============
        IBM is currently working on the following APARs which will  be
        available soon:

        AIX 4.1:  IX70236
        AIX 4.2:  IX70237

    NEC Corporation
    ===============
        NEC is vulnerable.  The  systems affected by this problem  are
        as follows:

        UX/4800
        UX/4800(64)
        EWS-UX/V(Rel4.2MP)
        EWS-UX/V(Rel4.2)
        UP-UX/V(Rel4.2MP)

        Patches are in progress and will be made available from:

        ftp://ftp.meshnet.or.jp/pub/48pub/security.

    Siemens-Nixdorf Informationssysteme AG
    ======================================
        We are investigating this problem.

    The Santa Cruz Operation
    ========================
        The following SCO operating systems are vulnerable:

        - SCO Open Desktop/Open Server 3.0, SCO UNIX 3.2v4
        - SCO OpenServer 5.0
        - SCO UnixWare 2.1

        SCO CMW+  3.0 is  not vulnerable  as bind  is not supported on
        CMW+ platforms.   SCO has  made an  interim fix  available for
        anonymous ftp:

        ftp://ftp.sco.com/SSE/sse008.ltr.Z - cover letter
        ftp://ftp.sco.com/SSE/sse008.tar.Z - replacement binaries

    Sun Microsystems, Inc.
    ======================
        We are producing patches.

    The  "best  practice"  for  operating  the publicly available BIND
    system can be either:

        * a heterogeneous solution that involves first installing BIND
          release 4.9.6 and then release 8.1.1, or

        * a  homogeneous solution  that involves  installing only BIND
          release 8.1.1.

    Check  CERT  advisory  CA-97.22  to  see  how  to  determine which
    solution you should use.

    You may configure bind to accept updates only from a single host.

        zone "my.net"
        {
         type master;
         file "my.net.zon";
         allow-update { 1.2.3.4; 127.0.0.1 };
        };

    If the update comes  from a host not  on the access list,  it will
    be rejected, and the attempt will be logged, like this:

    Jul 28 19:29:41 verdi named[2118]: unapproved update from [195.1.171.130].1594 for netsafe.no

    If you don't enable  updates for a zone,  or you enable them  only
    from  hosts  within  an  intelligent  (source  routing prohibited,
    source  addresses  checked)  firewall,  bind  is  immune  to   the
    "bind_nuke" attack published here recently.

    Updates  aren't  on  by  default,  and  according  to rfc 2136 dns
    updates  are  not  recommended  except  from  "localhost" which is
    assumed to be secure.