In [http://www.debian.org/security/2008/dsa-1571 Debian Security Advisory 1571] (New openssl packages fix predictable random number generator), the Debian Security Team disclosed a vulnerability in the openssl package that makes many cryptographic keys that are used for authentication (e.g. through SSH) or signing (e.g. web server certificates) potentially vulnerable.

End User Summary

The scope of the problem includes:

The following cryptographic tools are unaffected:

Identifying Weak Keys

Characteristics of potentially vulnerable keys:

Additionally, some keys may be compromised in the following situations:

Applications/protocols known to use these keys:

To fix this, first aptitude update && aptitude upgrade to install the new version of the openssl and libssl0.9.8 packages (the vulnerability is fixed in version 0.9.8c-4etch3 for etch and version 0.9.8g-9 for lenny/sid).

If you choose not to use the above aptitude command, note that all of the following packages must be upgraded (they all come from the same source package):

Then, regenerate and distribute any potentially vulnerable keys. Instructions for how to regenerate the keys for these applications are below. You can also test to see if keys are vulnerable using the dowkd.pl utility as described below.

How weak?

Is there any information on how weak these keys are? Are we talking brute-forceable in minutes, or days, or millennia? -- AsheeshLaroia

dowkd.pl has 262412 lines, with most of the containing hashes of known vulnerable keys. That may suggest that there are 2^18 possible keys.

OpenSSH (Server)

rm /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server

Note that your users will see a "IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!" warning when they next log on to your ssh server because the key has changed. They will need to edit $HOME/.ssh/known_hosts to remove the offending line before continuing; checking that the key fingerprint is correct, of course (the fingerprint of your new key can be found with ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key). You can remove the key from known_hosts by running "ssh-keygen -R hostname"

Also, note that your existing ssh connections shouldn't be interrupted.

OpenSSH (Client)

You will need to have a list of the openssh keys that you currently have and where they have been copied to. For each key that is vulnerable:

cd ~/.ssh
ssh-keygen -t rsa -f filename
ssh-copy-id -i filename hostname 

Replacing rsa by dsa if you prefer dsa keys and replacing filename and hostname with appropriate values.

Generic PEM Generation

This is just a reminder for those who generate PEM encoded certificates. Your site probably has other policies in place about how to manage keys which you should follow. Additionally, you may need to get the certificates signed again by a 3rd party Certificate Authority rather than by using a self-signed certificate as shown below:

cd /etc/ssl/private
openssl genrsa 1024 > mysite.pem
cd /etc/ssl/certs
openssl req -new -key ../private/mysite.pem -x509 -days 9999 -out mysite.pem

OpenVPN

BIND9

dovecot

Generate a new PEM as shown in "Generic PEM Generation" above (making sure that it is placed in the correct place according to your dovecot configuration, then restart dovecot:  invoke-rc.d dovecot restart .

postfix

Generate a new PEM as shown in "Generic PEM Generation" above (making sure that it is placed in the correct place according to your postfix configuration, then restart postfix:  invoke-rc.d postfix restart .

cyrus imapd

courier imap/pop3

Follow the "Generic PEM Generation" instructions and add a openssl gendh >> mysite.pem.

Apache2 SSL

dropbear

rm /etc/dropbear/*_host_key
dpkg-reconfigure dropbear

Testing keys using dowkd.pl

The security team has prepared a utility for you to test your keys to see if they have a fingerprint that matches a list of known-weak finger prints. Download [http://security.debian.org/project/extra/dowkd/dowkd.pl.gz dowkd.pl.gz ] ([http://security.debian.org/project/extra/dowkd/dowkd.pl.gz.asc gpg signature]):

cd /tmp
wget http://security.debian.org/project/extra/dowkd/dowkd.pl.gz
wget http://security.debian.org/project/extra/dowkd/dowkd.pl.gz.asc
gpg --keyserver subkeys.pgp.net --recv-keys 02D524BE
gpg --verify dowkd.pl.gz.asc
gunzip dowkd.pl.gz

/!\ Note that dowkd.pl produces many false positives and that the authors suggest that it may also produce false negatives. On that basis, you might decide that it is simply easier to regenerate your keys as described above.

Use dowkd.pl in the following ways:

SSH Server Host Key

Key is OK:

perl dowkd.pl host localhost
# localhost SSH-2.0-OpenSSH_4.3p2 Debian-9
# localhost SSH-2.0-OpenSSH_4.3p2 Debian-9

Key is weak:

perl dowkd.pl host localhost
# localhost SSH-2.0-OpenSSH_4.3p2 Debian-9
# localhost SSH-2.0-OpenSSH_4.3p2 Debian-9
localhost: weak key
localhost: weak key

SSH User Key

To check one user (someuser):

perl dowkd.pl user someuser
/home/someuser/.ssh/authorized_keys:1: warning: unparsable line
/home/someuser/.ssh/authorized_keys:3: warning: unparsable line
/home/someuser/.ssh/authorized_keys:4: weak key
/home/someuser/.ssh/authorized_keys:5: weak key

Notes:

To check all users:

perl dowkd.pl user

Other keys?

The tool is unable to parse PEM files at present.

While the tool is unable to parse PEM files, there is a way to convert PEM files to SSH-style public keys, which the tool can parse. I've not verified this method completely, it comes from information found at: http://webjob.sourceforge.net/Files/Recipes/openssl-convert-ssl-key-to-ssh-keypair.txt

cp /etc/apache/ssl.key/your.keyfile.key ~/.ssh/id_ssl
ssh-keygen -y -f ~/.ssh/id_ssl  > ~/.ssh/id_ssl.pub
./dowkd.pl file ~/.ssh/id_ssl.pub

I have as yet not determined how accurate this method is, but it seems to work reliably. Someone more familiar with the workings of ssh-keygen can confirm the reliability of this method. Scripting this test should be easy enough.

I don't know what kind of information is being requested, but it seems fairly easy. On first invocation of the tool, it generates a DB file from the "blacklist" contained in the DATA section of the script. If the DB exists, it is opened for reading. Once the DB exists, it uses ssh-keygen to retrieve the fingerprint of the public key presented to it by the executor of the script, and compares the fingerprint that it retrieves to the blacklist. If there is a match, then the script prints 'weak key'.

This is perhaps irrelevant now -- an earlier version of this tool didn't say "weak key" but just printed the key name. It also completely failed to parse correctly formed authorized_key files. Perhaps it has now been sufficiently refined as to now be understandable. This page has been a work in progress throughout the day and getting the bones of the content here so that it could then be added to by others was the priority.

Technical Summary

(If you want to add more technical details that an end-user doesn't need to know or isn't likely to understand, please add them here rather than making the above summary impossible for the average user to understand.)

Causes

It is important to understand that this problem was caused by trying to remove valgrind warnings related to the use of uninitialised memory within the openssl libraries. This was done to try to make it easier to debug C applications that use the openssl libraries which is a good thing to do.

A discussion of why this change was made can be found at [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516 #363516] and also on the [http://marc.info/?t=114651088900003&r=1&w=2 openssl-dev list] although it appears that a certain [http://www.links.org/?p=327 revisionist attitude] is being held with regards to that conversation.

Acknowledgements

This document was put together by the folks on [:] to help with user support. It would have been nice to have had the chance to prepare this (and the key rollover page) in the 5 days between the commit being made to pkg-openssl and the DSA being released. Particular credit to themill, dondelelcaro, stew, Maulklin, iobound for reading, writing and suggesting bits for this page.