OS and Software > All Things Unix > Heads Up: Debian OpenSSL RNG Vuln CVE-2008-0166

Heads Up: Debian OpenSSL RNG Vuln CVE-2008-0166

quote:

---

Luciano Bello discovered that the random number generator in Debian's
openssl package is predictable. This is caused by an incorrect
Debian-specific change to the openssl package (CVE-2008-0166). As a
result, cryptographic key material may be guessable.

This is a Debian-specific vulnerability which does not affect other
operating systems which are not based on Debian. However, other systems
can be indirectly affected if weak keys are imported into them.

It is strongly recommended that all cryptographic key material which has
been generated by OpenSSL versions starting with 0.9.8c-1 on Debian
systems is recreated from scratch. Furthermore, all DSA keys ever used
on affected Debian systems for signing or authentication purposes should
be considered compromised; the Digital Signature Algorithm relies on a
secret random value used during signature generation.

---

Actually, I think this is waffling on the use of the term "predictable", because in the random-number business it normally means that given one number produced by the RNG, one can compute, guess, or derive another number (the previous or the following number in the series).

When this is the case, it means that if I am on the system at the same time you're generating your SSH keys or SSL session, the random number I get will be computationally "close" to the random number you get, so I might be able to figure yours out.

My ability to exploit this vaporizes rapidly with the time difference between when I get my number and you get yours increases - it requires contemporaneous access to the same RNG.

But in the Debian case, it appears to be a much worse kind of predictable: it instead means that the RNG is pulling from a too-small pool of possible numbers, and though I might not be able to determine the next or prior number in the sequence, the pool of available numbers is small enough that I can attempt to brute-force the RNGs that produced it.

I have not studied the particular use of random numbers in SSL or SSH, but this looks yucky: if I know or suspect that your key came from a vulnerable Debian system, I can make a fair run as figuring out the key and can therefore decode your SSL session. And maybe even your SSH private key. I don't need to have access to your server to exploit it.

This really smells like bad news.

Edit - You could understand this problem as similar to taking a good, valid random number and using only the lower 16 bits instead of whatever the normal size is (though I doubt the actual bug is implemented this way).

Steve — who is not an expert on this area, and might be full of baloney

That's the attack as I understand it exactly. Thanks!

Thanks for the info.

Just stumbled upon this. Interesting point, not sure I entirely agree with it. But certainly in this case the author makes a good point.
--
»hillaryis404.org/

quote:

---

Usually it is bad to have any kind of dependency on uninitialised memory, but OpenSSL happens to include a rare case when its OK, or even a good idea: its randomness pool. Adding uninitialised memory to it can do no harm and might do some good, which is why we do it.

---

reply to BeesTea
Is there any reason to regenerate the host-wide keys in /etc/ssh or just those created with ssh-keygen for use in authorized_keys?

/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_dsa_key.pub
/etc/ssh/ssh_host_rsa_key.pub
/etc/ssh/ssh_host_rsa_key
 

For sure host keys would be vulnerable too. The public/private key exchange to build an ssh session pre-auth is almost identical to the one used for auth.

It's going to be a while before all the impact of this is fully understood I think. Thanks for pointing that out. It might be worth brain dumping all the places where SSL might get used like that.
--
Overpower, overcome.

reply to evilghost

quote:

---

Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key
material for use in X.509 certificates and session keys used in SSL/TLS
connections. Keys generated with GnuPG or GNUTLS are not affected,
though.

---

reply to BeesTea
I dissected the OpenSSH deb and this is the postinst script that runs to create the keys. Therefor, to recreate the host keys you can:

rm -f /etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_key /etc/ssh/ssh_host_dsa_key
ssh-keygen -q -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa
ssh-keygen -q -f /etc/ssh/ssh_host_dsa_key -N '' -t dsa
/etc/init.d/ssh restart
 

create_key() {
        msg="$1"
        shift
        hostkeys="$1"
        shift
        file="$1"
        shift
 
        if echo "$hostkeys" | grep -x "$file" >/dev/null && \
           [ ! -f "$file" ] ; then
                echo -n $msg
                ssh-keygen -q -f "$file" -N '' "$@"
                echo
                if type restorecon >/dev/null 2>&1; then
                        restorecon "$file.pub"
                fi
        fi
}
 
create_keys() {
        hostkeys="$(host_keys_required)"
 
        create_key "Creating SSH1 key; this may take some time ..." \
                "$hostkeys" /etc/ssh/ssh_host_key -t rsa1
 
        create_key "Creating SSH2 RSA key; this may take some time ..." \
                "$hostkeys" /etc/ssh/ssh_host_rsa_key -t rsa
        create_key "Creating SSH2 DSA key; this may take some time ..." \
                "$hostkeys" /etc/ssh/ssh_host_dsa_key -t dsa
}
 

That's going to make SO many ssh clients really, really unhappy

Necessary, obviously, but people are going to be seeing a lot of "man in the middle" type errors from ssh in the coming weeks.
--
»hillaryis404.org/

reply to evilghost
Yes. You need to regenerate them, they're required for the security of the session setup.

reply to BeesTea
Glad I'm running 6.06 LTS so I don't have to deal with re-creating my Apache SSL cert, my Dovecot/Postfix .pem, and my SSH keys...

reply to BeesTea
Ugh, ssh, apache2, postfix, vsftp, I have some cleaning up to do.

reply to BeesTea
I haven't tested it myself, but apparently this script can find affected keys:

»security.debian.org/project/extr···kd.pl.gz

It's a huge perl script, namely because it has the key data in the perl script itself.

Hope it's useful for some folks.
--
»hillaryis404.org/

reply to BeesTea
Script seems to work. At least it identifies weak keys and they go away when you run evilghost 's commands.

Speaking of evilghost , the first line, "ssh-keygen -q -f /etc/ssh/ssh_host_key -N '' -t rsa1" creates files called "ssh_host_key" and "ssh_host_key.pub" that didn't already exist on all the Debian boxes I've tried so far. Don't think they're really needed.

Fortunately a lot of my Debian hosts started life as Sarge boxes so a lot have been unaffected so far.
--
"Be safe be suspicious"

I don't think it (by default) supports RSA1 keys, and rightly so. They're quite insecure, relative to DSA and RSA2.
--
»hillaryis404.org/

reply to pflog
Script appears to work. Tried it against a Sarge-generated host keys and it was quiet. Tried it against a recently installed Etch server and it reported the weak keys. After upgrading and regenerating the host keys, it was quiet.

Excellent feedback. Thanks!
--
Overpower, overcome.

reply to Eatmeingreek

said by Eatmeingreek:

Script seems to work. At least it identifies weak keys and they go away when you run evilghost 's commands.

Speaking of evilghost , the first line, "ssh-keygen -q -f /etc/ssh/ssh_host_key -N '' -t rsa1" creates files called "ssh_host_key" and "ssh_host_key.pub" that didn't already exist on all the Debian boxes I've tried so far. Don't think they're really needed.

Fortunately a lot of my Debian hosts started life as Sarge boxes so a lot have been unaffected so far.