Debian SSH vulnerability

[QT]

PLEASE READ THE COMPLETE ARTICLE BY CLICKING HERE.



May 13, 2008 http://www.debian.org/security/faq
- ------------------------------------------------------------------------

Package : openssl
Vulnerability : predictable random number generator
Problem type : remote
Debian-specific: yes
CVE Id(s) : CVE-2008-0166

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.

The first vulnerable version, 0.9.8c-1, was uploaded to the unstable
distribution on 2006-09-17, and has since propagated to the testing and
current stable (etch) distributions. The old stable distribution
(sarge) is not affected.

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.

A detector for known weak key material will be published at:

http://security.debian.org/project/e...kd/dowkd.pl.gz
http://security.debian.org/project/e...wkd.pl.gz.asc/
(OpenPGP signature)

Instructions how to implement key rollover for various packages will be
published at:

http://www.debian.org/security/key-rollover/

The web site will be continuously updated to reflect new and updated
instructions on key rollovers for packages using SSL certificates.
Popular packages not affected will also be listed.

In addition to this critical change, two other vulnerabilities have been
fixed in the openssl package which were originally scheduled for release
with the next etch point release: OpenSSL's DTLS (Datagram TLS,
basically "SSL over UDP") implementation did not actually implement the
DTLS specification, but a potentially much weaker protocol, and
contained a vulnerability permitting arbitrary code execution
(CVE-2007-4995). A side channel attack in the integer multiplication
routines is also addressed (CVE-2007-3108).

For the stable distribution (etch), these problems have been fixed in
version 0.9.8c-4etch3.

For the unstable distribution (sid) and the testing distribution
(lenny), these problems have been fixed in version 0.9.8g-9.

We recommend that you upgrade your openssl package and subsequently
regenerate any cryptographic material, as outlined above.

Upgrade instructions
- --------------------

wget url
will fetch the file for you
dpkg -i file.deb
will install the referenced file.

If you are using the apt-get package manager, use the line for
sources.list as given below:

apt-get update
will update the internal database
apt-get upgrade
will install corrected packages

You may use an automated update by adding the resources from the
footer to the proper configuration.

PLEASE READ THE COMPLETE ARTICLE BY CLICKING HERE.

[ender]

First: updating SSH server host keys

To regenerate SSH host keys, the following commands will do the trick.

etch$ sudo su -

etch# cd /etc/ssh

etch# mkdir oldkeys-`date +"%Y%m%d"`

etch# cp ssh_host_*_key oldkeys-`date +"%Y%m%d"`

This will regenerate the DSA host key.
The output should be similar to what is shown below:
(Note: the "yes" piped to ssh-keygen simply answers the "overwrite (y/n)" prompt.)

etch# yes|ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ''
Generating public/private dsa key pair.
/etc/ssh/ssh_host_dsa_key already exists.
Overwrite (y/n)? Your identification has been saved in /etc/ssh/ssh_host_dsa_key.
Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub.
The key fingerprint is:
2f:9a:7a:cf:06:91:b9:5e:67:87:78:0e:17:4b:d3:32 root@etch

This will regenerate the RSA host key.
The output should be similar to what is shown below:
(Note: the "yes" piped to ssh-keygen simply answers the "overwrite (y/n)" prompt.)

etch# yes|ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ''
Generating public/private rsa key pair.
/etc/ssh/ssh_host_rsa_key already exists.
Overwrite (y/n)? Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
48:56:a3:2b:9c:32:4f:c0:bd:70:db:44:0d:9a:7f:2e root@etch

After this, SSH clients will complain about the host keys changing.

For users of the OpenSSH client, one will need to remove the old host key from the ~/.ssh/known_hosts file on their client machine. OpenSSH will give you the line number when it detects a key conflict.

For users of Putty, a dialog box should pop up indicating that the key has changed. There is a button (the exact text of which escapes me at the moment) to accept & store the new key.

Once the host keys are known to the clients once more, SSH should operate as it did prior to the regen.


Next: updating user SSH auth keys

If you are using SSH keys for authentication, they will also need to be regenerated. This can be done with the following command (note: run this as the user for whom the key is being generated, not root):

etch$ mkdir ~/.ssh/oldkeys-`date +"%Y%m%d"`
etch$ cp ~/.ssh/id_[rd]sa* ~/.ssh/oldkeys-`date +"%Y%m%d"`
etch$ ssh-keygen -t dsa -f ~/.ssh/id_dsa

It will ask if you want to overwrite the old key, and also prompt for a passphrase. I used the following command to get the new key into the authorized_keys files on my remote hosts:

etch$ cat ~/.ssh/id_dsa.pub|ssh othermachine 'cat > ~/.ssh/authorized_keys'

NOTE: This *WILL* overwrite your authorized_keys on othermachine. If you have other entries in there which you need to keep, it is best to edit the file manually.

[knightfoo]

The updated Debian Etch packages will automatically regenerate the SSH host keys for you. If it does not make new keys for some reason, a quicker way to regenerate the keys is to delete all of your host key files then run the post-install configuration script manually:

# mkdir /root/backup_keys
# mv /etc/ssh/ssh_host_* /root/backup_keys
# /var/lib/dpkg/info/openssh-server.postinst configure
Creating SSH2 RSA key; this may take some time ...
Creating SSH2 DSA key; this may take some time ...
Restarting OpenBSD Secure Shell server: sshd.

Note that the vulnerability also affects keys used to generate X.509 certificates; i.e. your standard, run of the mill web SSL certificate. This means that any SSL certificate created from a key generated by the vulnerable OpenSSL library could be compromised and should be reissued. I imagine certificate authorities are going to have a cow over this one.

[QT]

(Well hello stranger)

[brady474747]

Thanks knightfoo!

FWIW, I have one debian machine here and three others in office and none of them automatically updated their keys after updating openssl, so thanks for the quick and easy process!

[ender]

Thanks knightfoo!

FWIW, I have one debian machine here and three others in office and none of them automatically updated their keys after updating openssl, so thanks for the quick and easy process!

Neither did any of the 4 debian boxes which I updated; which is why (as I didn't know the proper debian method which knightfoo was kind enough to post) I did the write-up.

[SmallClanger]

Hi folks,

I maintain several Debian etch boxes. I went through the manual process on the first one before any package updates had been made available.

Just to clarify: updating the openssl package will not regenerate your host keys. The host keys are part of the openssh-client package. Updating this will regenerate the keys and install a second, dependent package: openssh-blacklist

The blacklist is a full list of known compromised 1k and 2k key fingerprints stored in /etc/ssh. The updated client package installs ssh-vulnkey which can be invoked to check a given key against these lists. This from a patched machine:

/etc/ssh# ls -l
total 4224
-rw-r--r-- 1 root root 2064867 May 13 14:23 blacklist.DSA-1024
-rw-r--r-- 1 root root 2064867 May 13 14:23 blacklist.RSA-2048
-rw-r--r-- 1 root root  132777 Mar  5  2007 moduli
-rw-r--r-- 1 root root    1422 Jan 30 12:23 ssh_config
-rw------- 1 root root     668 May 15 12:15 ssh_host_dsa_key
-rw------- 1 root root     668 Jan 29 20:20 ssh_host_dsa_key.broken
-rw-r--r-- 1 root root     598 May 15 12:15 ssh_host_dsa_key.pub
-rw-r--r-- 1 root root     598 Jan 29 20:20 ssh_host_dsa_key.pub.broken
-rw------- 1 root root    1675 May 15 12:15 ssh_host_rsa_key
-rw------- 1 root root    1675 Jan 29 20:20 ssh_host_rsa_key.broken
-rw-r--r-- 1 root root     390 May 15 12:15 ssh_host_rsa_key.pub
-rw-r--r-- 1 root root     390 Jan 29 20:20 ssh_host_rsa_key.pub.broken
-rw-r--r-- 1 root root    1873 Jan 30 12:23 sshd_config

/etc/ssh# ssh-vulnkey ssh_host_dsa_key.pub
Not blacklisted: 1024 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx ssh_host_dsa_key.pub
/etc/ssh# ssh-vulnkey ssh_host_dsa_key.pub.broken
COMPROMISED: 1024 yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy ssh_host_dsa_key.pub.broken

The command can be used against any public ssh key (this is only for ssh, I believe. Other ssl keys aren't covered)

http://wiki.debian.org/SSLkeys seems to be the dumping ground for all information regarding this issue.

Terry.