Vulnerability

    libdes

Affected

    Domestic US NetBSD-current between 19990624 and 20000622

Description

    Following is based on NetBSD Security Advisory 2000-007.  On  June
    24,  1999,   a  new   version  of   "libdes"  was   imported  into
    NetBSD-current.  This version was  derived from version 4 of  Eric
    Young's  libdes,  and  replaced  the  previous  version, which was
    derived from version 2 of Eric Young's libdes.  Certain  functions
    required  for  compatibility  with  the  DES library included with
    MIT's  Kerberos  v4  distribution  were  not  included  in the new
    version of Eric Young's libdes (which is also the version included
    in SSLeay and OpenSSL).

    Unfortunately, the replacement versions of these functions written
    during the integration process have a serious bug. If /dev/urandom
    is      not      present      and      functioning      correctly,
    des_init_random_number_generator seeds the random number generator
    with constant data, causing the generation of keys which are  easy
    to determine.   The following programs  which are included  in the
    NetBSD distribution are impacted by this bug:

        - /usr/bin/telnet
        - /usr/libexec/telnetd
        - /usr/sbin/kadmin
        - /usr/sbin/kdb_edit
        - /usr/sbin/kdb_init
        - /usr/sbin/kerberos
        - /usr/sbin/ksrvutil

    Other  programs  which  use  the  des_init_random_number_generator
    function, such as some programs which use Kerberos version 4,  are
    also impacted.   Kerberos service keys  which were generated  on a
    system exhibiting this bug *must* be regenerated, or the  Kerberos
    service principals in question will have no security.

    The   functions   reimplemented    for   the   integration    were
    des_set_random_generator_seed,       des_new_random_key,       and
    des_init_random_number_generator.  The  API used by  many Kerberos
    version 4 programs to obtain random DES keys is relatively simple.
    des_init_random_number_generator  is  called  to  initialize   the
    random number generator with a secret seed, such as a key obtained
    from the KDC.   Environmental data is  used to permute  the secret
    seed  so  that  multiple  callers  with  the  same  seed  will get
    different output streams from the random number generator.   After
    an     initial     use     of    des_init_random_number_generator,
    des_new_random_key is called  to get 64  bits at a  time of random
    data.

    Unfortunately,  in  the  implementation  present  in  NetBSD  from
    19990624 until 20000622, a misplaced "memset" call in the body  of
    des_init_random_number_generator  zeroes  the  seed  data  before,
    rather than  after, use.   While a  small amount  of environmental
    data is mixed  in on each  call to des_new_random_key,  the output
    will not be  sufficiently random to  provide reasonable levels  of
    security.   Fortunately,  if  /dev/urandom  is  present and can be
    read,  des_new_random_key  will  use  it  instead of the DES-based
    random number generator, and is thus not vulnerable.

    Credit  goes  to  Jason  Thorpe  for  noticing  the  problem while
    integrating  libcrypto  into  the  main  NetBSD source tree, which
    involved again replacing libdes.

Solution

    No formal releases of NetBSD are vulnerable.  NetBSD-current since
    20000622 is not vulnerable.  Systems running NetBSD-current should
    be upgraded  to a  source tree  later than  20000622.   You should
    ensure that  you are  building libdes  as a  symlink to libcrypto,
    from the  "lib/libdes" directory  in the  source tree  rather than
    from "domestic" or "crypto-us", which are obsolete.

    If  an  upgrade  is  not  possible,  a very quick workaround is to
    ensure  that  /dev/urandom  is  present  and  functioning  on your
    system.   It   is  important   to  confirm   not  just   that  the
    /dev/urandom  device  node  exists,  but  is  also readable by all
    users and kernel  random number driver  is in fact  present in the
    running kernel.  To verify, as an unprivileged user, type:

        dd if=/dev/urandom of=/dev/null bs=64 count=1

    at a shell prompt.  If the output of dd starts with the following,
    your system is not vulnerable:

        1+0 records in
        1+0 records out

    If it is not possible to patch your source tree, it is  imperative
    that  you  ensure  that  future  kernels always include the random
    number  generator,  or  your  system  will become vulnerable; make
    sure that

        pseudo-device rnd

    is  present  and  not  commented  out in your kernel configuration
    file.  You then need  to rebuild, install the newly  built kernel,
    and reboot. For more information on how to do this, see:

        http://www.netbsd.org/Documentation/kernel/#building_a_kernel

    If  neither  approach  is  feasible,  the  following  patch can be
    applied  to  src/crypto-us/lib/libdes/rnd_keys.c  in  a vulnerable
    source distribution of NetBSD to correct the problem:

    --- rnd_keys.c  1999/07/30 19:41:06     1.5
    +++ rnd_keys.c  2000/06/22 00:01:26
    @@ -75,12 +75,12 @@
       snprintf(accum, 512, "%ld%ld%d%s%d%qd", when.tv_sec, when.tv_usec,
                                         getpid(), hname, getuid(), *seed);
    
    -  memset(accum, 0, 512);
    -
       SHA1Update(&sha, (u_char *)accum, strlen(accum));
    
       SHA1Final(results, &sha);
    
    +  memset(accum, 0, 512);
    +
       des_random_seed(results);    /* XXX uses only first 8 bytes! */
    
       memset(results, 0, 20);

    Once the  patch is  applied, build  and install  a new  version of
    libdes.    If   the   system   in   question   is   a  server  for
    kerberos-authenticated  services,  you  should  change the service
    keys  for  the  system  once  the  system  software is upgraded to
    include  the  fixes  described  above;  you  can typically use the
    ksrvutil command to do this.