-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For background on the problem, please see: http://lists.debian.org/debian-security-announce/2008/msg00152.html
Debian are advising that for the last two years, their OpenSSL has been patched to essentially remove all randomness from the seed used by its random number generator, vastly reducing the possible number of keys in the keyspace of generated keys. The flaw was introduced by an over- zealous package maintainer in an attempt to suppress warnings from the Valgrind tester. He'd evidently removed one call too many - the call he removed, in looking like an equivalent but harmless call earlier on in the code which generated the Valgrind warning (about using uninitialised buffers as a potential further source of entropy), actually turned out to be the one which stirred entropy gathered from system-supplied randomness sources like /dev/?random and EGD into the entropy pot. For vulnerable OpenSSL versions, the only source of random data in the entropy pool was the pid of the process running the OpenSSL library. Sweet. This is quite some fuckup. It's shameful. Maybe we can learn something from it, although judging from the abundance of "Okay, we've learned, now let's carry on" comments floating out there in cyberspace, I'm afraid I have doubts. I think Debian are mostly to blame here for touching stuff they really don't understand and for being generally presumptive about the package maintenance, although the circumstances mean that others may well have had a part to play in this little debacle, most notably the OpenSSL team. Still, the vocal nature of the Debian defense is a bit disheartening, and it does make up the vast majority of the "Fire and forget" attitude. The other major worry, for me at least, is that this is not a good sign for Open Source. In general, perhaps, because we've found a flaw that shouldn't be there; but Debian is well-respected for use on servers, and their correctness and general organisation means that what they do has a big impact on the appearance of Open Source, irrespective of whether or not other open distributions and operating systems are affected. Sure, the flaw got spotted. But think: one man makes one mistake and commits a package, and everybody gets wind of it *two* years later because, up until now, it's never been thought important for regular users of a wide-spread binary-only distribution to review code changes. It made sense to the libcrypto team, but it doesn't make sense to us, and nor did it make sense to the maintainers of the OpenSSL package at Debian. Compared to proprietary software, the code at least gives us a fighting chance of fixing it; but many eyes does not mean all bugs are worth looking into, regardless of whether they are shallow. That's the really important thing here. That the side-effects should include cost and time for all the wide-reaching implications, on every distribution and on any platform using vulnerable keys, is really a second blow. Above all, though, we had better hope that people are encouraged to practice as much security as a result of this as possible, including peer review and secure design. This is open source, and security deserves a top priority. It's one thing that makes Open Source special. All keys generated on affected systems need to be regenerated. All affected keys may as well be considered compromised, no matter where they were used, whether on patched or unpatched systems, affected or unaffected systems, because their private keys can be found by brute force. All data exchanges that have taken place using such keys may as well also be considered trivially compromisable or already compromised. Patch OpenSSL on Debian or any distribution using it (like the Ubuntu family), then regenerate any keys in software using OpenSSL that were generated by a buggy OpenSSL. That includes OpenSSH, OpenVPN, DNSSec, X.509 certificates, and probably more. Vet all keys on your system(s); keys used for granting authorisation (such as OpenSSH user-generated public key authorisation keys), whose private key may have been generated by a buggy OpenSSL, may provide access to brute-force attackers to privileges owned by the owner of such keys. This is true whether or not the authorised key is stored on a vulnerable or unaffected system. Debian have provided a tool (linked from the advisory) for helping you to compare keys against a blacklist of weak creators. It works for SSH keys, and can also let you probe other hosts. I have removed all suspect keys from Bloodstone. They were all SSH keys in user home directories. Bloodstone itself is a Gentoo system; all its own keys, including SSH host keys and X.509 certificate, are fine. OpenPGP keys are not affected on any system, because GnuPG does not use OpenSSL for OpenPGP keys. You do not need to adjust any trust relationships to bloodstone, but if you were using authorised keys you will have to resubmit them after generating less weak keys. Bloodstone does not, unlike Debian or Ubuntu with upgraded OpenSSH, yet check for blacklisted keys at the SSH daemon. I might add that in future. By removing all affected keys, though, we won't be allowing attackers in with user privileges anyway. Cheers, Sabahattin - -- Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com> Address harvesters, snag this: [EMAIL PROTECTED] Phone: +44 20 88008915 Mobile: +44 7986 053399 http://sabahattin-gucukoglu.com/ -----BEGIN PGP SIGNATURE----- Version: PGP 8 Comment: QDPGP - http://community.wow.net/grt/qdpgp.html iQA/AwUBSC279yNEOmEWtR2TEQIVKQCgjMdBXk05bU2hg2j0GcoULM+RLM4AnA4M Z+yVZs625pSF3Eczraic2GGT =mf/q -----END PGP SIGNATURE----- -- [email protected] mailing list Send administrative requests (subscribe, unsubscribe, change options) to: [EMAIL PROTECTED] (use "help" in the Subject line for a summary of common options) You can also use the web interface at: https://sabahattin-gucukoglu.com/cgi-bin/lsg2.cgi For assistance, contact: [EMAIL PROTECTED]
