OVH Community, your new community space.

Debian warning : New openssl packages fix predictable random number generator


Bruno
15-05-2008, 02:00
http://www.debian.org/security/2008/dsa-1576

The recently announced vulnerability in Debian's openssl package (DSA-1571-1, CVE-2008-0166) indirectly affects OpenSSH. As a result, all user and host keys generated using broken versions of the openssl package must be considered untrustworthy, even after the openssl update has been applied.

1. Install the security updates

This update contains a dependency on the openssl update and will automatically install a corrected version of the libssl0.9.8 package, and a new package openssh-blacklist.

Once the update is applied, weak user keys will be automatically rejected where possible (though they cannot be detected in all cases). If you are using such keys for user authentication, they will immediately stop working and will need to be replaced (see step 3).

OpenSSH host keys can be automatically regenerated when the OpenSSH security update is applied. The update will prompt for confirmation before taking this step.

2. Update OpenSSH known_hosts files

The regeneration of host keys will cause a warning to be displayed when connecting to the system using SSH until the host key is updated in the known_hosts file. The warning will look like this:

Code:
    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
    @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
    IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
    Someone could be eavesdropping on you right now (man-in-the-middle attack)!
    It is also possible that the RSA host key has just been changed.
In this case, the host key has simply been changed, and you should update the relevant known_hosts file as indicated in the error message. It is recommended that you use a trustworthy channel to exchange the server key. It is found in the file /etc/ssh/ssh_host_rsa_key.pub on the server; it's fingerprint can be printed using the command:

Code:
    ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
In addition to user-specific known_hosts files, there may be a system-wide known hosts file /etc/ssh/known_hosts. This is file is used both by the ssh client and by sshd for the hosts.equiv functionality. This file needs to be updated as well.

3. Check all OpenSSH user keys

The safest course of action is to regenerate all OpenSSH user keys, except where it can be established to a high degree of certainty that the key was generated on an unaffected system.

Check whether your key is affected by running the ssh-vulnkey tool, included in the security update. By default, ssh-vulnkey will check the standard location for user keys (~/.ssh/id_rsa, ~/.ssh/id_dsa and ~/.ssh/identity), your authorized_keys file (~/.ssh/authorized_keys and ~/.ssh/authorized_keys2), and the system's host keys (/etc/ssh/ssh_host_dsa_key and /etc/ssh/ssh_host_rsa_key).

To check all your own keys, assuming they are in the standard locations (~/.ssh/id_rsa, ~/.ssh/id_dsa, or ~/.ssh/identity):

Code:
    ssh-vulnkey
To check all keys on your system:

Code:
    sudo ssh-vulnkey -a
To check a key in a non-standard location:

Code:
    ssh-vulnkey /path/to/key
If ssh-vulnkey says "Unknown (no blacklist information)", then it has no information about whether that key is affected. In this case, you can examine the modification time (mtime) of the file using "ls -l". Keys generated before September 2006 are not affected. Keep in mind that, although unlikely, backup procedures may have changed the file date back in time (or the system clock may have been incorrectly set). If in doubt, generate a new key and remove the old one from any servers.

4. Regenerate any affected user keys


OpenSSH keys used for user authentication must be manually regenerated, including those which may have since been transferred to a different system after being generated.

New keys can be generated using ssh-keygen, e.g.:

Code:
       $ ssh-keygen
       Generating public/private rsa key pair.
       Enter file in which to save the key (/home/user/.ssh/id_rsa):
       Enter passphrase (empty for no passphrase):
       Enter same passphrase again:
       Your identification has been saved in /home/user/.ssh/id_rsa.
       Your public key has been saved in /home/user/.ssh/id_rsa.pub.
       The key fingerprint is:
       00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 user@host
5. Update authorized_keys files (if necessary)

Once the user keys have been regenerated, the relevant public keys must be propagated to any authorized_keys files (and authorized_keys2 files, if applicable) on remote systems. Be sure to delete the lines containing old keys from those files.

In addition to countermeasures to mitigate the randomness vulnerability, this OpenSSH update fixes several other vulnerabilities:

CVE-2008-1483: Timo Juhani Lindfors discovered that, when using X11 forwarding, the SSH client selects an X11 forwarding port without ensuring that it can be bound on all address families. If the system is configured with IPv6 (even if it does not have working IPv6 connectivity), this could allow a local attacker on the remote server to hijack X11 forwarding.

CVE-2007-4752: Jan Pechanec discovered that ssh fails back to creating a trusted X11 cookie if creating an untrusted cookie fails, potentially exposing the local display to a malicious remote server when using X11 forwarding.

For the stable distribution (etch), these problems have been fixed in version 4.3p2-9etch1. Currently, only a subset of all supported architectures have been built; further updates will be provided when they become available.

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

We recommend that you upgrade your openssh packages and take the measures indicated above.

Bruno
14-05-2008, 00:18
- ------------------------------------------------------------------------
Debian Security Advisory DSA-1571-1 security@debian.org
http://www.debian.org/security/ Florian Weimer
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:



(OpenPGP signature)

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



This web site will be continously 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.


Debian GNU/Linux 4.0 alias etch


../..


http://www.debian.org/security/2008/dsa-1571