The Notorious, Catastrophic 2008 Debian OpenSSH Vulnerability
Debian OpenSSH Vulnerability, Jasone Blevins. (2008)
In May 2008, a bug was discovered in the Debian OpenSSL package which affected the seeding of the random number generator (RNG) used to generate keys. Any SSH keys generated by affected systems should be considered compromised. GnuPG keys are not affected. See the official Debian security advisory for details.
This does not mean that an attacker could immediately guess your private key, but because there was significantly less entropy being introduced into the seeding of the RNG, the key space was significantly reduced making a brute-force attack feasible. As I understand it, the primary source of entropy for seeding the RNG was originally uninitialized memory from the heap. Additional, more predictable components like the current process ID (an integer between 1 and 32,768) were also used. Due to an erroneous patch introduced in September 2006, uninitialized memory was no longer used in seeding the RNG leaving the process ID as the primary source of randomness. Thus, generated keys can be predicted to the extent that one knows how soon after boot time a key was generated. For example, SSH host keys are usually generated immediately after installation and so they are likely to have been generated by a processes with IDs, say, less than 500.
If it were not for this ever so small bit of “randomness,” this bug would likely have been discovered much sooner, before the patch made it to stable distributions, as someone would have noticed that all their SSH keys were the same. Unfortunately, as they say, bad cryptography looks the same as good cryptography.
Once the bug was discovered, Debian security updates were released that blacklisted the vulnerable keys, causing the system to fall back to a password-based login. If you have an affected key and try to log into an updated system, you may see a message like the following:
Public key 81:e6:75:64:17:5f:e2:ff:12:c3:ac:85:43:1e:6a:3c blacklisted (see ssh-vulnkey(1)); refusing to send itThus as long as your system is up to date, you can sleep well knowing that it won’t be compromised and update your key at your leisure. However, if you have been used to using
ssh-agentand key-based authentication, typing your password over and over will soon become burdensome and you’ll want to generate a new key.The remainder of this article discusses how to check your key and generate a new one if necessary. If you would like to read more about the situation, Russ Cox wrote a very nice article which provides some technical background and documents the decisions leading up to the offending patch. █