1 files changed, 167 insertions, 0 deletions

diff --git a/debian/README.compromised-keys b/debian/README.compromised-keys
new file mode 100644
index 000000000..7a9cb7657
--- /dev/null
+++ b/debian/README.compromised-keys
@@ -0,0 +1,167 @@
+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 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,
+OpenVPN and SSL certificates.
+
+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.
+
+== 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 ==
+
+OpenSSH:
+
+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):
+
+     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.
+
+OpenSSL:
+
+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.
+
+== Removing openssh-blacklist ==
+
+For the moment, the openssh-server package depends on openssh-blacklist, in
+order that the blacklist is deployed to the maximum possible number of
+systems to reduce the potential spread of worms exploiting this
+vulnerability. We acknowledge that this may be inconvenient for some small
+systems, but nevertheless feel that this was the best course of action.
+
+If you absolutely need to remove the blacklist from your system, then you
+can run the following commands to substitute a fake package for
+openssh-blacklist:
+
+  sudo apt-get install equivs
+  equivs-control openssh-blacklist.ctl
+  sed -i 's/^Package:.*/Package: openssh-blacklist/' openssh-blacklist.ctl
+  sed -i 's/^# Version:.*/Version: 9:1.0/' openssh-blacklist.ctl
+  equivs-build openssh-blacklist.ctl
+  sudo dpkg -i openssh-blacklist_1.0_all.deb
+
+Be warned: this circumvents a security measure for the sake of disk space.
+You should only do this if you have no other option, and if you are certain
+that no compromised keys will ever be generated on or copied onto this
+system.
+
+Once a sufficient amount of time and number of releases have passed, the
+openssh-blacklist package will be phased out.