1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
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.
|
