Re: instructions for Bacula /openssl vulnerability [corrected/revised]
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 <fs@WPI.EDU>.
> 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.
Reply to: