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.