Security Advisory 2000-007

Type securityvulns
Reporter Securityvulns
Modified 2000-06-23T00:00:00



             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


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:


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:

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-----