[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bacula-devel] Bacula affected by debian openssl vulnerability


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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-devel mailing list
Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/bacula-devel


This mailing list archive is a service of Copilotco.