From: Frank S. <fs@WPI.EDU> - 2008-05-16 13:54:47
|
I realize that, strictly speaking, this isn't a Bacula bug, but this is critical enough that it might be worth putting a statement up on the web page about the current debian openssl vulnerability. At least one person has already asked about it on the users list, and I'm sure that there are plenty more who are concerned about it. Short version - for the last three years, a bug introduced into the openssl libraries on debian has cut the actual entropy down in the random number generator to only 15 bits. This means that an attacker only has to try at most 2^15 (32,768) different values to crack anything protected by one of these certificates by brute force - pretty trivial on any reasonably modern computer. For those who want all the gory details: http://wiki.debian.org/SSLkeys http://www.debian.org/security/2008/dsa-1571 http://isc.sans.org/diary.html?storyid=4420 http://isc.sans.org/diary.html?storyid=4421 The fix is two part. First, you must upgrade openssl to a version where the random number generator is fixed. That's the easy part. The harder part is that you must regenerate any certificates or keys (ssh, SSL, TLS, etc) that were generated by the buggy library. Any data encrypted with certs from the buggy version is at risk, and should (ideally) be re-encrypted and the old version wiped. Bacula uses openssl certs in two places: communication encryption, and data encryption. The communication encryption is relatively straightforward. Regenerate and replace the certs, and any future data streams should be safe. If an attacker has captured old data streams, they will be vulnerable to decryption, but there's not much you can do about that. The data encryption part is much harder. Any volumes encrypted by these buggy certificates are also vulnerable to decryption by an attacker. Someone who's more familiar than I am with the data encryption code will have to comment on exactly what mechanism might work best, but anyone with such a volume should basically treat it as unencrypted until they have re-encrypted the volume data with a new, safe certificate. It's also worth noting that this would affect any master keys as well as client specific keys. It also looks like a good number of packages use 'openssl rand' to generate MD5 passwords. This obviously uses openssl to generate some entropy, so it may also be vulnerable (someone with more crypto skills than me care to comment either way?), so unless you've generated your own passwords using something other than a vulnerable openssl it's probably safest to consider them compromised and just generate new ones. -- Frank Sweetser fs at wpi.edu | For every problem, there is a solution that WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC |