HD Moore of Metasploit has tested a serious problem with Debian-based implementations — including Knoppix, Finnix, Mepis, Ubuntu and its derivatives, et al. — dating to September 17, 2006, of OpenSSL due to removal of code that was responsible for seeding random number generation (which is used to calculate encryption keys). This makes random number generation predictable and means keys are guessable/crackable. Moore writes that “Instead of mixing in random data for the initial seed, the only ‘random’ value that was used was the current process ID. On the Linux platform, the default maximum process ID is 32,768, resulting in a very small number of seed values being used for all PRNG operations.”
If we continue this process for all PIDs up to 32,767 and then repeat it for 2048-bit RSA keys, we have covered the valid key ranges for x86 systems running the buggy version of the OpenSSL library. With this key set, we can compromise any user account that has a vulnerable key listed in the authorized_keys file. This key set is also useful for decrypting a previously-captured SSH session, if the SSH server was using a vulnerable host key…
The interesting thing about these keys is how they are tied to the process ID. Since most Debian-based systems use sequential process ID values (incrementing from system boot and wrapping back around as needed), the process ID of a given key can also indicate how soon from the system boot that key was generated. If we look at the inverse of that, we can determine which keys to use during a brute force based on the target we are attacking. When attempting to guess a key generated at boot time (like a SSH host key), those keys with PID values less than 200 would be the best choices for a brute force. When attacking a user-generated key, we can assume that most of the valid user keys were created with a process ID greater than 500 and less than 10,000. This optimization can significantly speed up a brute force attack on a remote user account over the SSH protocol.
In his FAQ, HDM says, “It took two hours to generate the 1024-bit DSA and 2048-bit RSA keys for x86” using 31 Xeon cores clocked at 2.33Ghz. He also adds that “It should be possible to try all 32,767 keys of both DSA-1024 and RSA-2048 within a couple hours” barring anti-brute force scripts on the server.
In my recent page for re-engineering DSL for traditional hard drive installation, I recommended updating zlib, openssl, and openssh because of the age and (in)security of the packages upon which DSL was built. Security is not a one-time shot, it’s a matter of persistence and requires constant attention and commitment. My page was published before becoming aware of this particular issue, which doesn’t affect DSL, per se, because the versions affected are Debian Etch and later; DSL was built on Woody, which predates Sarge and this particular Debian/SSL issue.
Unfortunately, this problem goes beyond just Debian users (and users of Debian-based distros like DSL) because of the number of certificates exchanged between secure sessions involving affected servers. Certificates from Debian servers — from banks, from websites, etc. — are affected regardless if the end user uses Debian, Slackware, FreeBSD, OSX, or Windows. As Moore adds,
In the case of SSL keys, all generated certificates will be need to recreated and sent off to the Certificate Authority to sign. Any Certificate Authority keys generated on a Debian-based system will need be regenerated and revoked. All system administrators that allow users to access their servers with SSH and public key authentication need to audit those keys to see if any of them were created on a vulnerabile system. Any tools that relied on OpenSSL’s PRNG to secure the data they transferred may be vulnerable to an offline attack. Any SSH server that uses a host key generated by a flawed system is subject to traffic decryption and a man-in-the-middle attack would be invisible to the users. This flaw is ugly because even systems that do not use the Debian software need to be audited in case any key is being used that was created on a Debian system.
The Debian advisory notes,
This is a Debian-specific vulnerability which does not affect other operating systems which are not based on Debian. However, other systems can be indirectly affected if weak keys are imported into them.
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 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.
The first vulnerable version, 0.9.8c-1, was uploaded to the unstable distribution on 2006-09-17, and has since that date propagated to the testing and current stable (etch) distributions. The old stable distribution (sarge) is not affected.
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, though.
Anyone who’s used SSH and/or OpenVPN between their own and a Debian- or any of its derivatives- based computer/server needs to update and generate new keys. Users of all operating systems may also get pop up messages from their browsers over the coming days that secure sites they visit may have new or different certificates. I think users should read each new certificate to verify integrity because this could prove wide enough that criminals may take advantage of the confusion with their own dubious and insecure certificates, which could make a bad situation even worse.
This was a dumb mistake made by the removal of only a few lines of code. Sometimes dumb mistakes turn out to have the widest effects on users. Even those who don’t use Linux or Debian.