Re: [SECURITY] [DSA 1571-1] vulnerability of past SSH/SSL sessions
Simon Valiquette <v.simon@ieee.org> writes:
>
> It seems that people are insisting quite a lot on the bad keys, but
> what worry me a lot more is that, apparently and very logically, past
> ssh connections and any SSL session keys are to be considered
> compromised.
After hastily reviewing the OpenSSH and OpenSSL code, my read is that
past SSH sessions *should* be considered compromised. This would
appear to be true if *either* side was using a bad OpenSSL library at
time of connection, *regardless* of whether or not the RSA/DSA keys
involved were weak.
Obviously, independent verification of this state of affairs would be
helpful. Any volunteers?
My assessment is detailed here:
The SSH session is secured entirely by a key generated through a
Diffie-Hellman key exchange independent of either side's RSA/DSA key.
(The server RSA/DSA key plays only a peripheral role in the exchange
and does not contribute to the level of security.) During the D-H
exchange, the client:
C1. Generates a secret random number "x".
C2. Sends e = g^x mod p (where g and p are public) to the server.
The server:
S1. Generates a secret random number "y".
S2. Sends f = g^y mod p to the client, among other things.
Then, the client and server secure the session using the key: K = f^x
mod p = e^y mod p, as calculated by the client and server
respectively.
An attacker has "e" and "f" available in plaintext in the captured
exchange. If *either* "e" or "f" was generated using a weak random
number ("x" or "y" respectively), the attacker can determine its value
and calculate the session key K (i.e., using "x" and "f" or using "y"
and "e", whichever pair is available).
Looking at the OpenSSH code, the random numbers "x" and "y" are
generated by dh_gen_key(), which uses the OpenSSL random number
function BN_rand() frequently seeded with RAND_add(). Ultimately,
these call ssleay_rand_bytes() and ssleay_rand_add() respectively, and
the latter is the buggy function that was failing to add anything
useful to the entropy pool.
> 3. If only one of the computer involved have a flawed openssl, but
> none have a vulnerable host key, is It still practical to break the
> session key? If yes, about how long could It takes?
I think it requires precomputing only 65,536 numbers: g^x mod p for
each of the possible values of the bad random number "x". After that,
an attacker can calculate "x" from "e" without further computation for
any captured exchange and determine the session key immediately from
"x" and "f".
--
Kevin Buhr <buhr+debian@asaurus.net>
Reply to: