-----BEGIN PGP SIGNED MESSAGE-----


                 NetBSD Security Advisory 2000-007
                 =================================

Topic:		bad key generation in libdes if no /dev/urandom
Version:	Domestic US NetBSD-current between 19990624 and 20000622.
		No formal releases of NetBSD are vulnerable.
Severity:	high only if kerberos is in use and /dev/urandom is
		not present; none otherwise


Abstract
========

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.

Technical Details
=================

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.

Solutions and Workarounds
=========================

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.

Thanks To
=========

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

Revision History
================

	2000/06/21 - Initial version.

More Information
================

Information about NetBSD and NetBSD security can be found at
http://www.NetBSD.ORG/ and http://www.NetBSD.ORG/Security/.


Copyright 2000, The NetBSD Foundation, Inc.  All Rights Reserved.

$NetBSD: NetBSD-SA2000-007.txt,v 1.3 2000/06/22 00:51:03 sommerfeld Exp $

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBOVFjcj5Ru2/4N2IFAQE5HAQApt4zDoRIuqTbewuLB6d/JeLIR9wCgkfR
HkmMS7jmcszQGzpAa8/kcIDaciPcj/U0YTn208zt4MuNtOpKk0GySnnQmRPNq1om
9sz7B9XqCtGYe4gQVsi9IEoTsHV/Aojrlc6i1ASe4fI8x916gpNP8GEiX0dMPGei
nUPpDB3qK0c=
=wQ1F
-----END PGP SIGNATURE-----