Swap out your ssh keys
14 May 2008
Debian and Ubuntu are not random enough
There is has been a bug in random number generator on Debian (from Etch onwards) or Ubuntu (Feisty onwards). You should already have a security update for the number generator. If you have not yet accepted the update then do so.
The Debian and Ubuntu distributions have even made the warning pop up on user's screens. Just apply the update, see below, and replace your keys and you are done.
If you are on an operating system that has apt-get then you probably want to look at what is going on. If you are on Gentoo or another distribution then for now you can just smile quietly to yourself.
Bugs in the number generator are bad mojo because there are less combinations, depending on the severity of the bug, it makes a brute-force attack go from almost completely impossible, to either still very improbable down to theoretically possible [update: or in the Debian case, quite possible if certain things are known about the target system ].
SSH is often the first point of entry to a Linux machine (but not the last line of defense) so bugs here are particularly prominent.
However, lets not have a panic attack about it. There are a dozen ways to get into someone's machine. In proprietary software land, they probably would have just ignored this kind of theoretical exploit to keep their marketing team happy. For a proprietary software company, still existing in five years time is a higher priority than a theoretical brute-force attack using hardware of the future. Free/Open Source Software forces good security, your dirty laundry is washed in public. Today's theoretically possible attacks are tomorrow's malware. If we ignore all these things then we end up with an operating system akin to Windows.
If you are on Debian or Ubuntu, the security updates means that any new keys will be to the desired level of randomness, but your existing ones need to be ditched. The update manager does not do this for you in case you are then left unable to log into remote systems.
Swapping out your SSH keys
Cleaning this up is easy. Run:
sudo ssh-vulnkey -a
This outputs a line for each SSH key on your system:
Not blacklisted: 2048 <key fingerprint> <filename>
Not blacklisted: 1024 <key fingerprint> <filename>
COMPROMISED: 2048 <key fingerprint> <filename>
COMPROMISED: 2048 <key fingerprint> <filename>
Not blacklisted: 2048 <key fingerprint> <filename>
So the ones that came from Gentoo or another Linux distribution are okay as far as we know. The two Ubuntu ones we must delete or archive somewhere else. To delete the keys use rm.
Now we might like to generate replacements, so we can still use SSH as before:
ssh-keygen
So to make this simpler, one of the lines was: COMPROMISED: 2048 49:37:38:f4:86:28:ac:b1:7e:a6:df:bd:1d:a4:da:81 /home/warrior/.ssh/id_rsa.pub
That is the public key of the local machine. So we get rid of it:
rm /home/warrior/.ssh/id_rsa rm /home/warrior/.ssh/id_rsa.pub
Now we want a new one:
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/warrior/.ssh/id_rsa):
The brackets mean that is the default, so I press enter.
Next it finds an existing key (the private half of the existing keypair);
/home/warrior/.ssh/id_rsa already exists.
Overwrite (y/n)?
We want to overwrite it so we say we yes.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/warrior/.ssh/id_rsa.
Your public key has been saved in /home/warrior/.ssh/id_rsa.pub.
Now we are done.
1 Bug says...
Where can I get this ssh-vulnkey? I'd like to test my ssh key.
Posted at 4:55 p.m. on May 14, 2008
2 txwikinger says...
The ssh-vulnkey command is part of the openssh-client package in the security repo for ubuntu.
Posted at 9:22 p.m. on May 14, 2008
3 mkc says...
I just get a bunch of lines that say "Unknown (no blacklist information)". What am I doing wrong?
Posted at 10:31 p.m. on May 14, 2008
4 Zeth says...
mkc it means that it has no idea what the key is, the type of key is not provided for in their blacklists.
I presume you yourself know where the key came from? If it came from Debian or Ubuntu I would move or destroy the key anyway.
Posted at 10:48 p.m. on May 14, 2008
5 Cristian says...
This vulnerability only applies to ssh servers, right? Aren't they the ones that generate the keys? So if my client is Ubuntu and the server is Fedora everything's okay?
Posted at 11:31 p.m. on May 14, 2008
6 Ed says...
@Cristian: it applies to keys. If you generated a key on Ubuntu and then put it in authorized_keys on Fedora, it's possible that someone could brute force their way in to the Fedora server.
Posted at 3:02 a.m. on May 15, 2008
7 Krispy says...
mkc: debian only provided blacklists for 2048 bit RSA keys and 1024 bit DSA keys. If your key isn't one of those two types, then the blacklist isn't provided in the package. You can download one here: http://metasploit.com/users/hdm/tools/debian-openssl/ but it is nearly 100MB
Posted at 6:01 a.m. on May 15, 2008
8 Kennon says...
The openssh-blacklist debian package (now available, and required for the latest version of openssh-client and openssh-server) is now available. You should: apt-get update apt-get install openssh-blacklist apt-get upgrade
After that you'll have the ssh-vulnkey utility and can check.
Posted at 7:51 a.m. on May 15, 2008
9 Bug says...
@txwikinger: Thing is, I don't use Ubuntu and I can't remember where did I generate my key [I'm using Archlinux].
@Zeth: You should add the number of comments to the front page.
Posted at 1:29 p.m. on May 15, 2008
10 stefano says...
Apparently the bug makes a brute-force attack much easier than "theoretically possible with a supercomputer". http://metasploit.com/users/hdm/tools/debian-openssl/ It looks that the buggy code used the process ID as seed for generating the key, and there might only be 32,768 process IDs. Furthermore not all process ID are equally possible and one could use a range of 1000-3000 seeds and having a very high chance of producing a valid key.
Posted at 3:38 p.m. on May 15, 2008
11 Anonymous says...
Like stefano says, you are being VERY irresponsible by downplaying this as only "theoretically possible with a supercomputer". Linked on the page stefano mentioned is this:
http://milw0rm.com/exploits/5622
That will break into your computer in a couple hours is you're using public-key logins, which are considered the safest kind, and are used on many, many machines that are supposed to be extra secure.
This is a horrible, horrible problem, and dismissing it does nobody any favours. I'd really suggest you re-write this article to accurately portray how serious the problem is.
Posted at 9:45 p.m. on May 15, 2008
12 Zeth says...
To Anonymous,
I said to do three things: 1. Accept the update. 2. Replace your keys. 3. Don't have a panic attack about it.
And I still stand by that. Most non-technical users won't even be using openssh-server. While the update, blacklists and instructions on how to regenerate comes down automatically for those that do. Indeed, I think this episode shows how fast the free/open source community can move.
Everytime the open source software has a panic attack over an in-theory, technically possible, but not actually being used, 'exploit', then proprietary software people say "Look their software is no better, it is just as insecure as ours".
However, that is not true. There is a range of exploits, from theoretically possible with some serious preparation and knowledge about the target system, through to automated attacks that will work against any machine without the need for knowledge about it.
Posted at 8:34 a.m. on May 16, 2008
13 Zeth says...
To Anonymous,
I tried your script with some old SSH keys and it did not manage to break into an apparently vulnerable system.
Posted at 8:38 a.m. on May 16, 2008
14 Andy Canfield says...
The Ubuntu 8.04 update was flawed, in that it included a terminal screen and user prompt to tell about replacing the keys. Using the Ubuntu standard update manager, there is no terminal, so the configuration of ssl just hangs. I had to update 2-3 times, running dpkg each time to unscamble the package database. apt-get probably would have worked OK.
Posted at 3:25 p.m. on May 16, 2008
15 Jalada says...
It was definitely annoying to have to update all my SSH keys (as I'm an Ubuntu user predominately). I also had to update some of my OpenVPN keys, as they were also vulnerable as a result. OpenVPN contains similar programs to the OpenSSH packages - and on startup it checks to see if you have invalid keys. One good thing that came of it, is I took the time to make public key files for login without a password (using SSH Agent though, as passphrase-less keys are a security risk in themselves) on all my boxes as I went around checking all the keys, so now I have more efficient SSH logins! :)
http://jalada.havennetworks.com
Posted at 1:26 p.m. on May 18, 2008
16 Grugnog says...
This post (and all the comments so far!) miss out the most important thing requiring action with this vulnerability, which is to delete every instance of the old (vulnerable) public key from every server or account to which it has ever been added.
If you don't do this, every single one of these servers will be vulnerable.
From the Ubuntu advisory:
http://www.ubuntu.com/usn/usn-612-2
"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."
I have a blog post up which describes the process for updating, testing and securing your keys. http://www.civicactions.com/blog/howto_secure_your_ssh_ssl_and_openvpn_keys_generated_on_debian_ubuntu_and_related_distributions
Posted at 2:33 a.m. on May 19, 2008
17 Jiminy says...
This doesn't explain what to do when it says
"COMPROMISED: 1024 <key fingerprint> username@hostname"
That's not a file.
Posted at 6:20 a.m. on May 20, 2008
18 kherio says...
and what about the COMPROMISED is root@domain.com? where is it located? In /etc/ssh?
Posted at 10:01 p.m. on May 20, 2008
19 Jiminy says...
http://www.nomachine.com/news-read.php?idnews=237
Posted at 4:11 p.m. on May 25, 2008