COMMAND
	    libdes
SYSTEMS AFFECTED
	    Domestic US NetBSD-current between 19990624 and 20000622
PROBLEM
	    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.