Debian advisory for OpenSSL could lead to predictable cryptographic
keys being generated on affected systems. Unfortunately, because of the
way keys are used, especially by ssh, this can lead to problems on
systems that never installed the vulnerable library. In addition, because the
OpenSSL library is used in a wide variety
of services that require cryptography, a very large subset of security
tools are affected. This is a wide-ranging vulnerability that affects
a substantial fraction of Linux systems.
For a look at the chain of errors that led to the vulnerability, see
our front page article.
Here, we will concentrate on some of the details of the code, the impact of
the vulnerability, and what to do about it.
An excellent tool for finding memory-related bugs, Valgrind was used on an application that
used the OpenSSL library. It complained about the library using
uninitialized memory in two locations in crypto/rand/md_rand.c:
MD_Update(&m,buf,j); /* purify complains */
While the lines of code look remarkably similar (modulo the pre-processor
directive), their actual effect is very different.
The first is contained in the ssleay_rand_add() function, which is
normally called via the RAND_add() function. It adds the contents
of the passed in buffer to the entropy pool of the pseudo-random number
generator (PRNG). The other is contained in ssleay_rand_bytes(),
normally called via RAND_bytes(),
which is meant to return random bytes. It adds the contents
of the passed in buffer—before filling it with random bytes to return—to the entropy pool as well. The major difference
is that removing the latter might marginally reduce the entropy in the PRNG
pool, while removing the former effectively stops any entropy from being
added to the pool.
For both RAND_add() and RAND_bytes(), the buffer that
gets passed in may not have been initialized. This was evidently known by
the OpenSSL folks, but remained undocumented for others to trip over
later. The "#ifndef PURIFY" is a clue that someone, at some
point, tried to handle the same kind of problem that Valgrind was reporting
for the similar, but proprietary, Purify tool. While it isn't necessarily
wrong to add these uninitialized buffers to the PRNG pool, it is
something that tools like Valgrind will rightly complain about. Since it
is dubious whether it adds much in the way of entropy, while constituting a
serious hazard for uninitiated, some kind of documentation in the code
would seem mandatory.
The major response from the OpenSSL team seems to be from core team member Ben Laurie's
weblog, where he has a rant entitled "Vendors Are
Bad For Security". In it, and its follow-up, he makes some good points
about mistakes that were made, while seeming to be unwilling for OpenSSL to take any
share of the blame.
The end result is that OpenSSL would create predictable random numbers,
which would then result in predictable cryptographic keys. According to
Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key
material for use in X.509 certificates and session keys used in SSL/TLS
connections. Keys generated with GnuPG or GNUTLS are not affected,
that can detect some weak keys has also been released. It uses
256K hash values to detect the bad keys, which would imply 18-bits of
entropy in the PRNG pool of vulnerable OpenSSL libraries. By using hashes
of the keys in the detection program, the authors do not directly give away the key
values that get generated, but it should not be difficult for an attacker
to generate and use that list.
For affected Debian-derived systems, the cleanup is relatively
straightforward, if painful. The SSLkeys page on the Debian wiki
has specific information on how to remove weak keys along with how to
generate new ones for a variety of services affected. Obviously, none of those steps should be taken until
the OpenSSL package itself has been upgraded to a version that fixes the hole.
A bigger problem may be for those installations based on distributions that
were not directly affected because they did not distribute the vulnerable
OpenSSL library. Those machines may very well have weak keys installed in
user accounts as ssh authorized_keys. A user who generated a key
pair on some vulnerable host may have copied the public key to a host that
was not vulnerable.
This would allow an
attacker to access the account of that user by brute forcing the key from
the 256K possibilities.
Because of that danger, the
Debian project suspended
public key authentication on debian.org machines. In addition, all
passwords were reset because of the possibility that an attacker could have
captured them by decrypting the ssh traffic using one of the weak keys.
One would guess that debian.org machines would have a higher incidence of
weak keys, but any host that allows users to use ssh public key
authentication is potentially at risk.
The weak key detector (dowkd) has some fairly serious limitations:
dowkd currently handles OpenSSH host and user keys and OpenVPN shared
secrets, as long as they use default key lengths and have been created
on a little-endian architecture (such as i386 or amd64). Note that
the blacklist by dowkd may be incomplete; it is only intended as a
In order to ensure that there are no weak keys installed as public keys on
other hosts, it may be necessary to remove all authorized_keys
(and/or authorized_keys2) entries for all users. It may also be
wise to set all passwords to something unknown. Until that is done, there
still remains a chance that a weak key may allow access to an attacker. It
is a unpleasant task that needs to be done for those who administer a multi-user system.
to post comments)