summaryrefslogtreecommitdiff
path: root/debian/README.compromised-keys
diff options
context:
space:
mode:
Diffstat (limited to 'debian/README.compromised-keys')
-rw-r--r--debian/README.compromised-keys167
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 @@
1The following instructions relate to CVE-2008-0166. They were prepared by
2Matt Zimmerman, assisted by Colin Watson.
3
4== What Happened ==
5
6A weakness has been discovered in the random number generator used by OpenSSL
7on Debian and Ubuntu systems. As a result of this weakness, certain encryption
8keys are much more common than they should be, such that an attacker could
9guess the key through a brute-force attack given minimal knowledge of the
10system. This particularly affects the use of encryption keys in OpenSSH,
11OpenVPN and SSL certificates.
12
13This vulnerability only affects operating systems which (like Ubuntu) are based
14on Debian. However, other systems can be indirectly affected if weak keys are
15imported into them.
16
17We consider this an extremely serious vulnerability, and urge all users to act
18immediately to secure their systems.
19
20== Who is affected ==
21
22Systems 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
30and have openssh-server installed or have been used to create an OpenSSH key or
31X.509 (SSL) certificate.
32
33All OpenSSH and X.509 keys generated on such systems must be considered
34untrustworthy, regardless of the system on which they are used, even after the
35update has been applied.
36
37This includes the automatically generated host keys used by OpenSSH, which are
38the basis for its server spoofing and man-in-the-middle protection.
39
40The 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
49OpenSSH:
50
511. 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
622. 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
783. 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
1084. 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
1265. 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
132OpenSSL:
133
1341. Install the security update
135
1362. Create new certificates to replace any server or client certificates in use
137 on the system
138
1393. 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
144For the moment, the openssh-server package depends on openssh-blacklist, in
145order that the blacklist is deployed to the maximum possible number of
146systems to reduce the potential spread of worms exploiting this
147vulnerability. We acknowledge that this may be inconvenient for some small
148systems, but nevertheless feel that this was the best course of action.
149
150If you absolutely need to remove the blacklist from your system, then you
151can run the following commands to substitute a fake package for
152openssh-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
161Be warned: this circumvents a security measure for the sake of disk space.
162You should only do this if you have no other option, and if you are certain
163that no compromised keys will ever be generated on or copied onto this
164system.
165
166Once a sufficient amount of time and number of releases have passed, the
167openssh-blacklist package will be phased out.