Fallout from the OpenSSL debacle
A lively debate has begun on the causes and consequences of the vulnerability in Debian's OpenSSL package and on Debian's culpability for it. Ben Laurie, OpenSSL developer and co-founder of the Apache Foundation, unleashed a scathing rant in a blog entry entitled Vendors Are Bad For Security. He believes that package maintainers should not play with source code they don't understand. Instead they should talk to the developers who can assess the patches and integrate them into the source code, effectively contributing their fixes upstream. According to Laurie, had Debian followed this policy, the OpenSSL problem would never have arisen.
Responsibility does not in this case lie exclusively with the maintainers of the Debian OpenSSL package. They were apparently fully aware that the change would result in a loss of randomness, for which reason they consulted the OpenSSL developers list to ensure that what they were doing was OK before introducing the fatal error into the package. No objections were registered, even after the event. Laurie backpedals somewhat in a subsequent blog entry and admits to communication problems within the OpenSSL team.
It is perfectly normal for Linux distributors to fiddle around in the source code to integrate patches and security updates into their packages. For smaller projects in particular, it can take a good deal of time for changes and bug fixes to be integrated into the original source code. Since, for stability reasons, distributors do not generally use the latest versions, they often need to backport patches into older versions. Martin Schulze and Florian Weimer from the Debian Project confirmed this to heise Security. They note that according to the developer guidelines, Debian maintainers are expected to work closely with upstream developers so that any changes can be integrated into the original source code.
The trigger for the changes to the OpenSSL package were error messages in Valgrind, a quality control tool which reported possible memory leaks in the encryption software. The changes made by Debian were intended to stop abnormal access to uninitialised memory – generally indicative of a programming error. But according to Laurie, instead of removing the specific procedure calls to the uninialised memory areas, the 'fix' completely prevented the
ssleay_rand_add() function from adding data to the entropy pool. However, uninialised memory is just one of many possible sources of entropy.
As a result, in generating random numbers the Debian OpenSSL only had recourse to the 16 bit Linux process ID. This meant that SSH and SSL/TSL keys generated with it could be guessed using a simply brute force attack. Test tools and exploits for the weak SSH keys up to 4096 bits in length are now doing the rounds – one such is included in the Metasploit Framework. These exploits are based on key lists generated by calculating the key from each of the 65536 possible process IDs. Programs for cracking SSH key logins are only effective if users have saved weak SSH keys for password-less logins on an SSH host.
The situation regarding X.509 certificates for SSL and TLS remains unclear. A method for converting X.509 keys in PEM format into SSH keys for testing is described in the Debian wiki, however wiki contributors report that test programs designed for SSH do not sound the alarm when presented with certificates generated using vulnerable versions of OpenSSL. In case of doubt, users should regenerate all SSL and SSH keys generated since September 2006 and revoke all certificates issued using these keys. Affected certification authorities are likely to have their work cut out in the coming days.
- Debian package of OpenSSL generates weak keys, heise Security report
- Vendors Are Bad For Security, blog entry by Ben Laurie
- The Debian wiki with notes on the OpenSSL vulnerability