crypto/openssh-5/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 generated much more frequently than they should be, such that an
   9 attacker could guess the key through a brute-force attack given minimal
  10 knowledge of the system.
  11
  12 We consider this an extremely serious vulnerability, and urge all users to act
  13 immediately to secure their systems.
  14
  15 == Who is affected ==
  16
  17 Systems which are running any of the following releases:
  18
  19  * Debian 4.0 (etch)
  20  * Ubuntu 7.04 (Feisty)
  21  * Ubuntu 7.10 (Gutsy)
  22  * Ubuntu 8.04 LTS (Hardy)
  23  * Ubuntu "Intrepid Ibex" (development): libssl <= 0.9.8g-8
  24
  25 and have openssh-server installed or have been used to create an OpenSSH key or
  26 X.509 (SSL) certificate.
  27
  28 All OpenSSH and X.509 keys generated on such systems must be considered
  29 untrustworthy, regardless of the system on which they are used, even after the
  30 update has been applied.
  31
  32 This includes the automatically generated host keys used by OpenSSH, which are
  33 the basis for its server spoofing and man-in-the-middle protection.
  34
  35 The specific package versions affected are:
  36
  37  * Debian 4.0: libssl <= 0.9.8c-4etch3
  38  * Ubuntu 7.04: libssl <= 0.9.8c-4ubuntu0.2
  39  * Ubuntu 7.10: libssl <= 0.9.8e-5ubuntu3.1
  40  * Ubuntu 8.04: libssl <= 0.9.8g-4ubuntu3
  41
  42 == What to do if you are affected ==
  43
  44 OpenSSH:
  45
  46 1. Install the security updates
  47
  48    Once the update is applied, weak user keys will be automatically rejected
  49    where possible (though they cannot be detected in all cases).  If you are
  50    using such keys for user authentication, they will immediately stop working
  51    and will need to be replaced (see step 3).
  52
  53    OpenSSH host keys can be automatically regenerated when the OpenSSH security
  54    update is applied.  The update will prompt for confirmation before taking
  55    this step.
  56
  57 2. Update OpenSSH known_hosts files
  58
  59    The regeneration of host keys will cause a warning to be displayed when
  60    connecting to the system using SSH until the host key is updated in the
  61    known_hosts file.  The warning will look like this:
  62
  63    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  64    @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
  65    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  66    IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
  67    Someone could be eavesdropping on you right now (man-in-the-middle attack)!
  68    It is also possible that the RSA host key has just been changed.
  69
  70    In this case, the host key has simply been changed, and you should update
  71    the relevant known_hosts file as indicated in the error message.
  72
  73 3. Check all OpenSSH user keys
  74
  75    The safest course of action is to regenerate all OpenSSH user keys,
  76    except where it can be established to a high degree of certainty that the
  77    key was generated on an unaffected system.
  78
  79    Check whether your key is affected by running the ssh-vulnkey tool, included
  80    in the security update.  By default, ssh-vulnkey will check the standard
  81    location for user keys (~/.ssh/id_rsa, ~/.ssh/id_dsa and ~/.ssh/identity),
  82    your authorized_keys file (~/.ssh/authorized_keys and
  83    ~/.ssh/authorized_keys2), and the system's host keys
  84    (/etc/ssh/ssh_host_dsa_key and /etc/ssh/ssh_host_rsa_key).
  85
  86    To check all your own keys, assuming they are in the standard
  87    locations (~/.ssh/id_rsa, ~/.ssh/id_dsa, or ~/.ssh/identity):
  88
  89      ssh-vulnkey
  90
  91    To check all keys on your system:
  92
  93      sudo ssh-vulnkey -a
  94
  95    To check a key in a non-standard location:
  96
  97      ssh-vulnkey /path/to/key
  98
  99    If ssh-vulnkey says "No blacklist file", then it has no information
 100    about whether that key is affected.
 101
 102 4. Regenerate any affected user keys
 103
 104    OpenSSH keys used for user authentication must be manually regenerated,
 105    including those which may have since been transferred to a different system
 106    after being generated.
 107
 108    New keys can be generated using ssh-keygen, e.g.:
 109
 110    $ ssh-keygen
 111    Generating public/private rsa key pair.
 112    Enter file in which to save the key (/home/user/.ssh/id_rsa):
 113    Enter passphrase (empty for no passphrase):
 114    Enter same passphrase again:
 115    Your identification has been saved in /home/user/.ssh/id_rsa.
 116    Your public key has been saved in /home/user/.ssh/id_rsa.pub.
 117    The key fingerprint is:
 118    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 user@host
 119
 120 5. Update authorized_keys files (if necessary)
 121
 122    Once the user keys have been regenerated, the relevant public keys must
 123    be propagated to any authorized_keys files on remote systems.  Be sure to
 124    delete the affected key.
 125
 126 OpenSSL:
 127
 128 1. Install the security update
 129
 130 2. Create new certificates to replace any server or client certificates in use
 131    on the system
 132
 133 3. If certificates have been generated for use on other systems, they must be
 134    found and replaced as well.