debian/README.compromised-keys

   1 The following instructions relate to CVE-2008-0166. They were prepared by
   2 Matt Zimmerman, assisted by Colin Watson.
   3
   4 == What Happened ==
   5
   6 A weakness has been discovered in the random number generator used by OpenSSL
   7 on Debian and Ubuntu systems.  As a result of this weakness, certain encryption
   8 keys are much more common than they should be, such that an attacker could
   9 guess the key through a brute-force attack given minimal knowledge of the
  10 system.  This particularly affects the use of encryption keys in OpenSSH,
  11 OpenVPN and SSL certificates.
  12
  13 This vulnerability only affects operating systems which (like Ubuntu) are based
  14 on Debian.  However, other systems can be indirectly affected if weak keys are
  15 imported into them.
  16
  17 We consider this an extremely serious vulnerability, and urge all users to act
  18 immediately to secure their systems.
  19
  20 == Who is affected ==
  21
  22 Systems which are running any of the following releases:
  23
  24  * Debian 4.0 (etch)
  25  * Ubuntu 7.04 (Feisty)
  26  * Ubuntu 7.10 (Gutsy)
  27  * Ubuntu 8.04 LTS (Hardy)
  28  * Ubuntu "Intrepid Ibex" (development): libssl <= 0.9.8g-8
  29
  30 and have openssh-server installed or have been used to create an OpenSSH key or
  31 X.509 (SSL) certificate.
  32
  33 All OpenSSH and X.509 keys generated on such systems must be considered
  34 untrustworthy, regardless of the system on which they are used, even after the
  35 update has been applied.
  36
  37 This includes the automatically generated host keys used by OpenSSH, which are
  38 the basis for its server spoofing and man-in-the-middle protection.
  39
  40 The specific package versions affected are:
  41
  42  * Debian 4.0: libssl <= 0.9.8c-4etch3
  43  * Ubuntu 7.04: libssl <= 0.9.8c-4ubuntu0.2
  44  * Ubuntu 7.10: libssl <= 0.9.8e-5ubuntu3.1
  45  * Ubuntu 8.04: libssl <= 0.9.8g-4ubuntu3
  46
  47 == What to do if you are affected ==
  48
  49 OpenSSH:
  50
  51 1. Install the security updates
  52
  53    Once the update is applied, weak user keys will be automatically rejected
  54    where possible (though they cannot be detected in all cases).  If you are
  55    using such keys for user authentication, they will immediately stop working
  56    and will need to be replaced (see step 3).
  57
  58    OpenSSH host keys can be automatically regenerated when the OpenSSH security
  59    update is applied.  The update will prompt for confirmation before taking
  60    this step.
  61
  62 2. Update OpenSSH known_hosts files
  63
  64    The regeneration of host keys will cause a warning to be displayed when
  65    connecting to the system using SSH until the host key is updated in the
  66    known_hosts file.  The warning will look like this:
  67
  68    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  69    @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
  70    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  71    IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
  72    Someone could be eavesdropping on you right now (man-in-the-middle attack)!
  73    It is also possible that the RSA host key has just been changed.
  74
  75    In this case, the host key has simply been changed, and you should update
  76    the relevant known_hosts file as indicated in the error message.
  77
  78 3. Check all OpenSSH user keys
  79
  80    The safest course of action is to regenerate all OpenSSH user keys,
  81    except where it can be established to a high degree of certainty that the
  82    key was generated on an unaffected system.
  83
  84    Check whether your key is affected by running the ssh-vulnkey tool, included
  85    in the security update.  By default, ssh-vulnkey will check the standard
  86    location for user keys (~/.ssh/id_rsa, ~/.ssh/id_dsa and ~/.ssh/identity),
  87    your authorized_keys file (~/.ssh/authorized_keys and
  88    ~/.ssh/authorized_keys2), and the system's host keys
  89    (/etc/ssh/ssh_host_dsa_key and /etc/ssh/ssh_host_rsa_key).
  90
  91    To check all your own keys, assuming they are in the standard
  92    locations (~/.ssh/id_rsa, ~/.ssh/id_dsa, or ~/.ssh/identity):
  93
  94      ssh-vulnkey
  95
  96    To check all keys on your system:
  97
  98      sudo ssh-vulnkey -a
  99
 100    To check a key in a non-standard location:
 101
 102      ssh-vulnkey /path/to/key
 103
 104    If ssh-vulnkey says "Unknown (no blacklist information)", then it has no
 105    information about whether that key is affected.  If in doubt, destroy the
 106    key and generate a new one.
 107
 108 4. Regenerate any affected user keys
 109
 110    OpenSSH keys used for user authentication must be manually regenerated,
 111    including those which may have since been transferred to a different system
 112    after being generated.
 113
 114    New keys can be generated using ssh-keygen, e.g.:
 115
 116    $ ssh-keygen
 117    Generating public/private rsa key pair.
 118    Enter file in which to save the key (/home/user/.ssh/id_rsa):
 119    Enter passphrase (empty for no passphrase):
 120    Enter same passphrase again:
 121    Your identification has been saved in /home/user/.ssh/id_rsa.
 122    Your public key has been saved in /home/user/.ssh/id_rsa.pub.
 123    The key fingerprint is:
 124    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 user@host
 125
 126 5. Update authorized_keys files (if necessary)
 127
 128    Once the user keys have been regenerated, the relevant public keys must
 129    be propagated to any authorized_keys files on remote systems.  Be sure to
 130    delete the affected key.
 131
 132 OpenSSL:
 133
 134 1. Install the security update
 135
 136 2. Create new certificates to replace any server or client certificates in use
 137    on the system
 138
 139 3. If certificates have been generated for use on other systems, they must be
 140    found and replaced as well.
 141
 142 == Removing openssh-blacklist ==
 143
 144 For the moment, the openssh-server package depends on openssh-blacklist, in
 145 order that the blacklist is deployed to the maximum possible number of
 146 systems to reduce the potential spread of worms exploiting this
 147 vulnerability. We acknowledge that this may be inconvenient for some small
 148 systems, but nevertheless feel that this was the best course of action.
 149
 150 If you absolutely need to remove the blacklist from your system, then you
 151 can run the following commands to substitute a fake package for
 152 openssh-blacklist:
 153
 154   sudo apt-get install equivs
 155   equivs-control openssh-blacklist.ctl
 156   sed -i 's/^Package:.*/Package: openssh-blacklist/' openssh-blacklist.ctl
 157   sed -i 's/^# Version:.*/Version: 9:1.0/' openssh-blacklist.ctl
 158   equivs-build openssh-blacklist.ctl
 159   sudo dpkg -i openssh-blacklist_1.0_all.deb
 160
 161 Be warned: this circumvents a security measure for the sake of disk space.
 162 You should only do this if you have no other option, and if you are certain
 163 that no compromised keys will ever be generated on or copied onto this
 164 system.
 165
 166 Once a sufficient amount of time and number of releases have passed, the
 167 openssh-blacklist package will be phased out.