via Reddit, this Debian Security announcement:
‘Luciano Bello discovered that the random number generator in Debian’s
openssl package is predictable. This is caused by an incorrect
Debian-specific change to the openssl package (CVE-2008-0166). As a result,
cryptographic key material may be guessable.
It is strongly recommended that all cryptographic key material which has been
generated by OpenSSL versions starting with 0.9.8c-1 on Debian systems (ie since 2006! –jm) is recreated from scratch. Furthermore, all DSA keys ever used
on affected Debian systems for signing or authentication purposes should be
considered compromised; the Digital Signature Algorithm relies on a secret
random value used during signature generation.’
and, of course, here’s the Ubuntu Security Notice for the hole:
Who is affected
Systems which are running any of the following releases:
- Ubuntu 7.04 (Feisty)
- Ubuntu 7.10 (Gutsy)
- Ubuntu 8.04 LTS (Hardy)
- Ubuntu “Intrepid Ibex” (development): libssl <= 0.9.8g-8
- Debian 4.0 (etch) (see corresponding Debian security advisory)
and have openssh-server installed or have been used to create an OpenSSH
key or X.509 (SSL) certificate. All OpenSSH and X.509 keys generated on
such systems must be considered untrustworthy, regardless of the system on
which they are used, even after the update has been applied. This includes
the automatically generated host keys used by OpenSSH, which are the basis
for its server spoofing and man-in-the-middle protection.
It was apparently caused by this incorrect “fix” applied by the Debian maintainers to their package. One wonders why that fix never made it upstream.
Bad news….
Update: Ben Laurie tears into Debian for this:
What can we learn from this? Firstly, vendors should not be fixing problems
(or, really, anything) in open source packages by patching them locally -
they should contribute their patches upstream to the package maintainers. Had
Debian done this in this case, we (the OpenSSL Team) would have fallen about
laughing, and once we had got our breath back, told them what a terrible idea
this was. But no, it seems that every vendor wants to “add value” by getting
in between the user of the software and its author.
+1!
For what it’s worth, we in Apache SpamAssassin work closely with our Debian
packaging team, tracking the debbugs traffic for the spamassassin package, and one of the Debian packagers is even on the SpamAssassin PMC.
So that’s one way to reduce the risk of upstream-vs-package fork bugs like this, since we’d have spotted that change going in, and nixed it before it caused this failure.
Here’s a question: should the OpenSSL dev team have monitored the bug traffic for Debian and
the other packagers? Do upstream developers have a duty to monitor downstream
changes too?
This comment puts it a little strongly, but is generally on the money in this regard:
the important part for OpenSSL is to find a way to escape the blame for their fuck-up. They failed to publish the correct contact address for such important questions regarding OpenSSL. Branden (another commenter –jm) noted that the mail address mentioned by Ben is not documented anywhere. It is OpenSSL’s responsibility that they allowed the misuse of openssl-dev for offtopic questions and then silently moving the dev stuff to a secret other list nobody outside OpenSSL knew about.
I’m sure Debian is willing to take their fair share of the blame if OpenSSL finally admits that their mistake played a major role here as well. After all the Debian maintainer might have misrepresented the nature of his plans, but he gave warning signs and said he was unsure. But as it appears now all the people who might have noticed secretly left openssl-dev, the documented place for that kind of questions. This is hardly the fault of the maintainer.
Update 2: this Reddit comment explains the hole in good detail:
Valgrind was warning about unitialized data in the buffer passed into ssleay_rand_bytes, which was causing all kinds of problems using Valgrind. Now, instead of just fixing that one use, for some reason, the Debian maintainers decided to also comment out the entropy mixed in from the buffer passed into ssleay_rand_add. This is the very data that is supposed to be used to see the random number generator; this is the actual data that is being used to provide real randomness as a seed for the pseudo-random number generator. This means that pretty much all data generated by the random number generator from that point forward is trivially predictable. I have no idea why this line was commented out; perhaps someone, somewhere, was calling it with uninitialized data, though all of the uses I’ve found were with initialized data taken from an appropriate entropy pool.
So, any data generated by the pseudo-random number generator since this patch should be considered suspect. This includes any private keys generated using OpenSSH on affected Debian systems. It also includes the symmetric keys that are actually used for the bulk of the encryption.
A pretty major fuck-up, all told.
Update 3: Here’s a how-to page on wiki.debian.org put together by the folks from the #debian IRC channel. It has how-to information on testing your keys for vulnerability using a script called ‘dowkd.pl’, details of exactly what packages and keys are vulnerable, and instructions on how to regenerate keys in each of the (many) affected apps.
It notes this about Apache2 SSL keys:
According to folks in #debian-security, if you have generated an SSL key (normally the step just prior to generating the CSR, and then sending it off to your SSL certificate provider), then the certificate should be considered vulnerable.
So, bad news — SSL keys will need to be regenerated. Add ‘costly’ to the list of downsides. (Yet another update: this hasn’t turned out quite that badly after all — many CAs are now offering free reissuance of affected certs.)
Looking at ‘dowkd.pl’, it gets even worse for ssh users. It appears the OpenSSH packages on affected Debian systems could only generate 1 of only 262148 distinct keypairs. Obviously, this is trivial to brute-force. With a little precomputation (which would only take 14 hours on a single desktop!), an attacker can generate all of those keypairs, and write a pretty competent SSH worm. :(
Update: voila, precomputed keypairs, and figures on the viability of remote brute-forcing the keyspace in 11 minutes.
Tags: debian, holes, openssh, openssl, security, ubuntu, vulnerabilities
