1. incident
1.1. who
1.1.1. Luciano Bello discovered that the random number generator in Debian's openssl package is predictable. This is caused by an incorrect Debian-specific change to the openssl package (CVE-2008-0166). As a result, cryptographic key material may be guessable.
1.2. what
1.3. when
1.4. where
1.5. why?
1.6. response
1.7. analysis
1.8. threat
1.9. comments
1.9.1. Remember patching isn't enough, you need to regenerate keys generated on these machines! Including those used in SSL certificates (X.509).
1.9.2. The greatest irony? All of these problems were caused by an attempt to make the software more secure two years ago.
1.9.3. cf. netscape
1.10. Really a Black Swan?
2. Author
2.1. Luke O'Connor
2.2. mind map used for this blog post
3. links
3.1. Debian wiki
3.1.1. # weak keys for both clients and servers (see section "Identifying Weak Keys below") # all key types that were generated using openssl (this includes RSA and DSA keys) # compromise of other keys or passwords that were transmitted over an encrypted link that was set up using weak keys. Note that this last point means that passwords transmitted over ssh to a server with a weak dsa server key could be compromised too; see the Debian project's reaction to this.
3.1.2. weakness in OpenSSL as used by Debian
3.1.3. many apps impacted
3.1.3.1. gives lots of detail on how to detect and rollover keys for various apps
3.1.4. CSR checker
3.1.5. how weak?
3.1.5.1. weak version only used PID as seed
3.1.5.2. 2^15-1 values
3.1.5.3. Non-broken OpenSSL seeds from PID and /dev/urandom.
3.1.6. detail
3.1.6.1. This was caused by an overzealous, well-intentioned elimination of code that was believed to have no impact on security. (Please do note from the above links that this was discussed with the !OpenSSL team and that no objections were raised at the time.)
3.1.6.2. the code change
3.1.6.3. The second of these is in ssleay_rand_bytes where buf is used as an output buffer. It had already been marked as a bad idea when -DPURIFY was in effect, because Purify (and valgrind, naturally) dislike this use of an output buffer as input. This use of MD_Update is dubious but shouldn't hurt as long as the mixing function of the PRNG is "sufficiently good". The removal of this call to MD_Update should not meaningfully alter the entropy available in the pool -- that is, OpenSSL does not depend upon uninitialized memory for its correct operation. The first call, however, is in ssleay_rand_add where buf is used as an INPUT buffer, to add entropy to the pool. Failing to call MD_Update there means that the pool will never actually get the entropy intended for it.
3.2. debian project post
3.2.1. On May 13th, 2008
3.2.2. Luciano Bello discovered that the random number generator in Debian's openssl package is predictable. This is caused by an incorrect Debian-specific change to the openssl package (CVE-2008-0166). As a result, cryptographic key material may be guessable.
3.2.3. 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.
3.2.4. 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.
3.2.5. 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.
3.3. metasploit
3.3.1. Removing this code has the side effect of crippling the seeding process for the OpenSSL PRNG. 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.
3.3.2. All SSL and SSH keys generated on Debian-based systems (Ubuntu, Kubuntu, etc) between September 2006 and May 13th, 2008 may be affected.
3.3.3. lists other impacts as well
3.3.4. When creating a new OpenSSH key, there are only 32,767 possible outcomes for a given architecture, key size, and key type. The reason is that the only "random" data being used by the PRNG is the ID of the process.
3.4. heise security
3.4.1. Since a faulty patch in 2006, the OpenSSL library used by Linux distribution Debian has been generating weak cryptographic keys.
3.4.2. Security expert Luciano Bello has now discovered a critical vulnerability in the OpenSSL package which makes the random number sequences, and therefore keys generated, predictable.
3.4.3. The problem only affects Debian and distributions derived from it, such as Ubuntu and Knoppix.
3.4.4. OpenSSL provides connection security for many important network services, such as the Apache web server, the SSH login service, the OpenVPN service, the Bind name server, S/MIME e-mail encryption and the trustworthiness of digital signatures. This could enable attackers to listen in on and manipulate SSL connections, obtain unauthorised access to SSH servers or poison DNS server caches. Encryption systems such as PGP and GnuPG, which are not based on SSL or TLS, are not affected.
3.5. sec focus
3.5.1. A flaw in the way that OpenSSL is implemented in the Ubuntu and Debian distributions of Linux have earned the software an unenviable adjective in the world of encryption: Predictable.
3.6. SANS diary
3.6.1. But this is not all – keep in mind that ANY cryptographic material created on vulnerable systems can be compromised. If you generated SSL keys on such Debian or Ubuntu systems, you will have to recreate the certificates and get them signed again. An attacker can even decrypt old SSH sessions now.
3.7. Ben Laurie
3.7.1. The result of this is that for the last two years (from Debian’s “Etch” release until now), anyone doing pretty much any crypto on Debian (and hence Ubuntu) has been using easily guessable keys. This includes SSH keys, SSL keys and OpenVPN keys.
3.7.2. What can we learn from this? Firstly, vendors should not be fixing problems (or, really, anything) in open source packages by patching them locally - they should contribute their patches upstream to the package maintainers.
3.7.3. Had Debian done this in this case, we (the OpenSSL Team) would have fallen about laughing, and once we had got our breath back, told them what a terrible idea this was. But no, it seems that every vendor wants to “add value” by getting in between the user of the software and its author.
3.7.3.1. breaking Linus' Law
3.7.4. Secondly, if you are going to fix bugs, then you should install this maxim of mine firmly in your head: never fix a bug you don’t understand. I’m not sure I’ve ever put that in writing before, but anyone who’s worked with me will have heard me say it multiple times.
3.7.5. Valgrind tracks the use of uninitialised memory. Usually it is bad to have any kind of dependency on uninitialised memory, but OpenSSL happens to include a rare case when its OK, or even a good idea: its randomness pool.
3.7.5.1. 177 comments
3.7.5.2. rant
3.7.6. more aftermath
3.7.6.1. clarification
3.7.6.2. 55 comments
3.8. Emergent
3.8.1. ok commentary
3.9. DR
3.9.1. HD Moore record time exploit
3.9.2. These lines were removed because they caused the Valgrind and Purify tools to produce warnings about the use of uninitialized data in any code that was linked to OpenSSL.
3.9.3. Just goes to show you, no matter how great your tool set is, and I do like Valgrind, you have to understand how they work and more importantly how your code works.
3.9.3.1. well you have to know what the programmer is thinking
3.9.4. No tool can be smart enough to tell you that the warning its complaining about with uninitialized data should be ignored (or at least fixed and not removed from the codebase) because it will effectively render the encryption you are trying to accomplish neutered.
3.10. Reg
3.10.1. One reader forwarded an excerpt from an internal discussion within the Debian Security Team that suggested the bug resides within OpenSSL itself and dates from May 2006. This pointed to possible flaws in OpenSSL 0.9.8b-1. However, the same source later told us, the flaw was later pinned down to OpenSSL 0.9.8c, as described in Debian's advisory. "They're still not revealing the full truth, particularly the fact the keyspace involved is only 215 possible permutations per architecture and thus very easily compromised if someone has a botnet at their disposal," our source said.
3.11. Reg 2
3.11.1. It's been more than a week since Debian patched a massive security hole in the library the operating system uses to create cryptographic keys for securing email, websites and administrative servers. Now the hard work begins, as legions of admins are saddled with the odious task of regenerating keys too numerous for anyone to estimate.
3.11.2. Certificates for defective keys will have to be revoked, new keys will have to be generated and, in the case of SSL certificates, registered with VeriSign or another certificate authority. No one knows how many keys need to be replaced, but it could number in the hundreds of thousands or millions. The keys are used for Secure Sockets Layer (SSL) transactions, which authenticate servers handling trusted websites and email, and to authenticate Secure Shell (SSH), which provides encrypted channels between sensitive computers.
3.11.3. The heft and tedium of tracking down, testing and regenerating so many keys, and the cost of paying certificate authorities to register them, has left some people feeling pessimistic about the prospects the problem will be fixed anytime soon.
3.11.3.1. LT
3.11.4. "I can't imagine how painful this will be for people who are using large data centers with hundreds of certificates," Ellis said.
3.11.5. The Debian bug was introduced in September 2006. It vastly reduces the amount of entropy used when programs like the Apache webserver, Sendmail, Exim and some implementations of Kerberos use OpenSSL to perform basic cryptographic functions. As a result, attackers can crack SSL keys, x.509 certificate keys, SSH keys, and digital signatures in fewer than 33,000 guesses, rather than the seemingly-infinite number of tries that would normally be required.
3.11.6. Tools available from Ubuntu and Metasploit author HD Moore are designed to aid in the process of detecting weak keys, but Appelbaum, the independent researcher, says certain conditions will prevent even diligent searches from finding everything. For example, keys with nonstandard sizes may not be flagged even though they're vulnerable.
3.12. HS2
3.12.1. 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.
3.12.2. 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.
3.13. HS3
3.13.1. best discussion
3.13.2. last page
3.14. online test tool
3.14.1. SSL Guardian