On Mon, 2008-06-02 at 13:16 -0700, Ross Boylan wrote: > I've attached some instructions for cleaning up the security of bacula, > a backup system, after the recent openssl vulnerability. I'm doing this > with the permission of the original author, Frank Sweetser <[EMAIL > PROTECTED]>. > I have deleted the initial portion of his message, which gives general > background on the vulnerability, since that info is already available. It looks as if the entire message was attached. The bacula-specific part begins at "The harder part is that you must regenerate....".
While I'm at it, here's the section with some editorial changes, including a warning to keep your old keys. Note a number of open issues: ------------------------------------------------------------ Bacula uses openssl certs in two places: communication encryption, and data encryption. The data encryption part raises more challenges. Any volumes encrypted by these buggy certificates are also vulnerable to decryption by an attacker. Ideally, you should re-encrypt the data and destroy the old backup. 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. If you still wish easy access to the weakly encrypted data on old backup volumes, you should retain the old keys. After that, you should regenerate and replace your bacula certificates. Data encryption from then on will be secure. The communication encryption is straightforward. After regenerating the certificates, 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. [RB: not sure if it's necessary to reload or restart bacula for the changes to take effect] [RB: I'm not sure if the next section applies to bacula, though it does have some automatically generated passwords under Debian. The issue it raises obviously affects other packages too.] 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. --------------------------------------------------------------- by Frank Sweetser, with revisions by Ross Boylan I, Ross Boylan, release my changes into the public domain. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
