Vulnerability

    BIND

Affected

    - All versions of BIND with dnskeygen, up to and including BIND 8.2.4
    - All versions of BIND with dnssec-keygen, up to and including BIND 9.1.2

Description

    Following  is  based  on  a  ISS  Advisory.   A flaw exists in the
    dnskeygen  utility  under  BIND  version  8  and the dnssec-keygen
    utility  included  with  BIND  version  9.   The keys generated by
    these utilities are stored in two files.  In the case of  HMAC-MD5
    shared  secret  keys  that  are  used  for  dynamic updates to DNS
    servers,  the  same  secret  keying  material  is  present in both
    files.   Only  one  of  the  files  is  configured by default with
    strong  access   control.  The   resulting  exposure   may   allow
    unauthorized local users to  obtain the keying information.   This
    may allow  attackers to  update DNS  servers that  support dynamic
    DNS updates.

    Keys for DNS Transactional Signatures (TSIG) are generated by  the
    dnskeygen  utility  under  BIND  version  8  or  the dnssec-keygen
    utility under BIND  version 9.   The keys generated  are stored in
    two files  based on  the key  name and  key type.   These keys are
    "shared secret" keys for the HMAC-MD5 algorithm and are  sensitive
    keying material that must be kept confidential.

    Sensitive keying  information generated  for TSIG  and Dynamic DNS
    is stored  in both  key files,  as well  as all keying information
    necessary to make dynamic updates to the DNS server.

    This flaw  only affects  sites that  use Dynamic  DNS updates with
    HMAC-MD5 keys and does not  affect any sites that only  use static
    zone  files  (the  majority  of  BIND  installations).  Sites that
    perform dynamic DNS updates  from otherwise secured systems  (such
    as  a  dedicated  DHCP  server  having  no  common  users) are not
    affected by this flaw.

    So, if  HMAC-MD5 keys  are used  to control  access to dynamic DNS
    updates, the potential exists for sensitive keying information  to
    be read  by unauthorized  users.   Once exposed,  these users then
    have  the  ability  to  update  DNS  information  in  the servers,
    leading to further compromise.

    If HMAC-MD5 keys are only  relied on for message integrity  on the
    wire or are only stored on systems that are not accessed by  users
    who would be restricted from access to such keying material  (such
    as an autonomous DHCP server), this problem may not be serious.

    If HMAC-MD5 keys are  used to control authentication  from servers
    and those servers  have users who  are not intended  to be granted
    authorization to perform dynamic DNS updates, this problem can  be
    serious.

    Unauthorized dynamic DNS  updates may result  in DNS poisoning  or
    corruption,  which  can  lead  to  further  compromise  of related
    systems.  TSIG  and HMAC-MD5 keys  are used for  more than Dynamic
    DNS.  All  uses of TSIG  and HMAC-MD5 keys  may be compromised  by
    this exposure.

    ISS  X-Force  would  like  to  thank  Paul  Vixie of ISC and Brian
    Wellington of Nominum.  This advisory was primarily researched  by
    Michael H. Warfield of the ISS X-Force.

Solution

    BIND 9 users should upgrade to BIND 9.1.3rc1 or higher.

    BIND 8.3 is  scheduled to be  available sometime in  the July 2001
    timeframe.  Until BIND 8.3 is released, BIND 8 users should  refer
    to the workarounds described below.

    BIND  administrators  should  inspect  all  keys  for correct file
    permissions after upgrading BIND.

    If a system is permitted to issue dynamic DNS updates to a  master
    DNS server and access is authenticated using HMAC-MD5 signed  TSIG
    signatures, check permissions on all "*.key" and "*.private" files
    used for TSIG  purposes.  If  unauthorized users can  access these
    files, the  potential for  compromise of  the keying  material and
    unauthorized updates to the DNS servers exists.

    The following two commands will reveal relevant key files that may
    contain sensitive keying data.

        find / -name 'K*.+157+[0-9][0-9][0-9][0-9][0-9].key' -perm +066

        find / -name 'K*.+157+[0-9][0-9][0-9][0-9][0-9].private' -perm +066

    If run as "root" or another superuser account, these commands  may
    reveal files that are  otherwise protected by directory,  path, or
    ACL permissions.  Change  permissions on all existing  dnssec .key
    files and .private files to mode 600 or stronger.

    Create dnssec keys only  in directories that have  permissions and
    ownership configured  to deny  unauthorized access  to the  keying
    material.

    Set umask to 066 before running dnssec-keygen or dnskeygen.  Files
    will then be created with permission 600 or stronger.  If there is
    any chance  that keys  have already  been exposed  or compromised,
    generate new keys with stronger storage permissions.