[Midnightbsd-cvs] src: README.compromised-keys: Alert users to the Debian ssh key issue.
laffer1 at midnightbsd.org
laffer1 at midnightbsd.org
Fri May 16 15:53:34 EDT 2008
Alert users to the Debian ssh key issue.
-------------- next part --------------
@@ -0,0 +1,134 @@
+The following instructions relate to CVE-2008-0166. They were prepared by
+Matt Zimmerman, assisted by Colin Watson.
+== What Happened ==
+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 generated much more frequently than they should be, such that an
+attacker could guess the key through a brute-force attack given minimal
+knowledge of the system.
+We consider this an extremely serious vulnerability, and urge all users to act
+immediately to secure their systems.
+== Who is affected ==
+Systems which are running any of the following releases:
+ * Debian 4.0 (etch)
+ * Ubuntu 7.04 (Feisty)
+ * Ubuntu 7.10 (Gutsy)
+ * Ubuntu 8.04 LTS (Hardy)
+ * Ubuntu "Intrepid Ibex" (development): libssl <= 0.9.8g-8
+and have openssh-server installed or have been used to create an OpenSSH key or
+X.509 (SSL) certificate.
+All OpenSSH and X.509 keys generated on such systems must be considered
+untrustworthy, regardless of the system on which they are used, even after the
+update has been applied.
+This includes the automatically generated host keys used by OpenSSH, which are
+the basis for its server spoofing and man-in-the-middle protection.
+The specific package versions affected are:
+ * Debian 4.0: libssl <= 0.9.8c-4etch3
+ * Ubuntu 7.04: libssl <= 0.9.8c-4ubuntu0.2
+ * Ubuntu 7.10: libssl <= 0.9.8e-5ubuntu3.1
+ * Ubuntu 8.04: libssl <= 0.9.8g-4ubuntu3
+== What to do if you are affected ==
+1. Install the security updates
+ 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):
+ 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 "No blacklist file", then it has no information
+ about whether that key is affected.
+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 at 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.
+1. Install the security update
+2. Create new certificates to replace any server or client certificates in use
+ on the system
+3. If certificates have been generated for use on other systems, they must be
+ found and replaced as well.
More information about the Midnightbsd-cvs