I've updated openssh-server and openssh-client to the latest version on
c0003, nestor, casper, iliad, and ghost. The update for Ubuntu 8.04 was as
indicated below, however, the update for Ubuntu 7.10 was not - instead of a
version number of 1:4.6p1-5ubuntu0.3, this version was skipped and the
version installed was 1:4.6p1-5ubuntu0.4. It might be worth keeping in mind.
Also, I think the libssl update/key regeneration I did before corrected the
security vulnerability, because after running "sudo ssh-vulnkey -a" as
indicated below, the results showed that none of our keys were blacklisted
(part of the ssh-server install was a blacklist of keys not to use).
--John
-----Original Message-----
From: ubuntu-security-announce-bounces@lists.ubuntu.com
[mailto:ubuntu-security-announce-bounces@lists.ubuntu.com] On Behalf Of
Jamie Strandboge
Sent: Tuesday, May 13, 2008 8:28 AM
To: ubuntu-security-announce@lists.ubuntu.com
Cc: full-disclosure@lists.grok.org.uk; bugtraq@securityfocus.com
Subject: [USN-612-2] OpenSSH vulnerability
A weakness has been discovered in the random number generator used
by OpenSSL on Debian and Ubuntu systems. As a result of this
weakness, certain encryption keys are much more common than they
should be, such that an attacker could guess the key through a
brute-force attack given minimal knowledge of the system. This
particularly affects the use of encryption keys in OpenSSH.
This vulnerability only affects operating systems which (like
Ubuntu) are based on Debian. However, other systems can be
indirectly affected if weak keys are imported into them.
We consider this an extremely serious vulnerability, and urge all
users to act immediately to secure their systems.
The following Ubuntu releases are affected:
Ubuntu 7.04
Ubuntu 7.10
Ubuntu 8.04 LTS
This advisory also applies to the corresponding versions of
Kubuntu, Edubuntu, and Xubuntu.
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:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@
@ 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.
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):
$ ssh-vulnkey
To check all keys on your system:
$ sudo ssh-vulnkey -a
To check a key in a non-standard location:
$ ssh-vulnkey /path/to/key
If ssh-vulnkey says "Unknown (no blacklist information)",
then it has no information about whether that key is affected.
If in doubt, destroy the key and generate a new one.
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.:
$ 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 on
remote systems. Be sure to delete the affected key.
--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
05-15-2008, 05:46 AM
"Felipe Figueiredo"
OpenSSH vulnerability
John,
On Tue, May 13, 2008 at 3:28 PM, John Bulcher <jbulcher@starkart.net> wrote:
> I've updated openssh-server and openssh-client to the latest version on
> c0003, nestor, casper, iliad, and ghost. The update for Ubuntu 8.04 was as
> indicated below, however, the update for Ubuntu 7.10 was not - instead of a
> version number of 1:4.6p1-5ubuntu0.3, this version was skipped and the
> version installed was 1:4.6p1-5ubuntu0.4. It might be worth keeping in mind.
Then you're late. It should have skipped to 1:4.6p1-5ubuntu0.5
instead. Please see USN-612-5. There was a regression, and a bug fixed
after the advisory you mentioned.
regards
FF
--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
OpenSSH vulnerability
