In May of 2008, researchers found a flaw in the Debian GNU/Linux operating system's random number generator, making any OpenSSL keys generated during the past 20 months so predictable that they could be correctly guessed in a matter of hours. In this tip, let's look at how this flaw came about and whether it has security implications for organizations other than those that use Debian.
Debian GNU/Linux, a particular distribution of the Linux operating system, is the result of a volunteer effort to create a free Unix-compatible operating system complete with a suite of applications. Like any operating system, it provides services to application programs that run on it. To provide cryptographic services such as Secure Sockets Layer (SSL), the OS uses the open source OpenSSL cryptography library.
Many encryption algorithms require a random value to seed or start the generation of a key. The problem with computers, however, is that they are not good at generating non-deterministic, high-quality random values. That's why you are often asked to move your mouse or type randomly on your keyboard when generating a digital certificate, as it provides some random values that the computer can use to initiate encryption. Failing to correctly generate truly random values for keys has caused a number of problems, including vulnerabilities in Kerberos, the X Window System, and the Network File System protocol.
Back in 2006, a developer working on the Debian project kept receiving compiler warnings of possible memory leaks in the OpenSSL package because of uninitialized memory, use of which is shunned as a bad development practice. Debian consulted the OpenSSL team but for unclear reasons it decided to go ahead with its own fix before the issue had been broadly assessed.
Unfortunately, as Debian researcher Luciano Bello discovered, instead of removing the specific procedure calls to the uninitialized memory areas, Debian's changes prevented any random data from being used during key generation. Therefore the Debian OpenSSL was only using a finite number of possible Linux process IDs to generate SSH and SSL/TSL keys, making them predictable. In fact, an attacker could figure them out by using a simple brute force attack, potentially compromising encryption keys and the data they protected.
A fix was released in May of this year, but what are the effects of this security flaw? Although it only directly affects Debian and other Debian-based distributions, such as Ubuntu, other systems can be indirectly affected if vulnerable keys generated by these systems have been imported into them. Affected keys include DSA, SSH, OpenVPN, DNSSEC, and those used in X.509 digital certificates and session keys used in SSL/TLS connections.
So, for example, any Digital Signature Algorithm (DSA) keys generated by an affected Debian system and used for signing or authentication purposes should be considered compromised; the Digital Signature Algorithm relies on a random value used during signature generation.
The aspect of this vulnerability that concerns me most is that those affected need to do more than just apply a patch: After updating the software, new keys must be generated. Organizations that rely on Debian-based distributions with OpenSSL to generate a certificate signing request (CSR) and private keys for SSL certificates will also have to regenerate their private keys and request certificate reissues. But without patching, security managers run the risk of leaving encryption and authentication vulnerable to hackers -- and yes, there are already scripts available online that allow brute forcing of vulnerable SSH keys.
Although no sites or communication channels have been reported compromised, and no real-world attacks have occurred as of yet, any site using these weak certificates is vulnerable to attackers seeking to impersonate a site or compromise the confidentiality of its communication channels. If there is any question about the integrity of keys, organizations should regenerate all cryptographic keys generated on Debian systems since September 2006 and revoke all certificates issued using those keys.
While this vulnerability was dealt with quickly once it was discovered, the way in which it was created has no doubt sullied the reputation of open source software somewhat. Does it suggest deeper security issues for Linux? I don't think so. But what it does do is highlight the need for close dialog between developers within the open source community. Better communication can help to ensure the integrity of critical and widely used modules.
About the author:
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Mike is the guest instructor for several SearchSecurity.com Security Schools and, as a SearchSecurity.com site expert, answers user questions on application security and platform security.
