SSH/SSL vulnerability in Debian since late 2006

Oops

It was revealed yesterday that there has been a great big security hole in the Debian-distributed SSL code, introduced in late 2006. This ill-advised Debian modification meant that all SSH and SSL keys were insufficiently random (the change removed part of the random seeding which normally takes place). This means that instead of there being a total of $BIG_NUM possible keys, there were only around 260,000 possible keys. This makes brute-forcing the key almost trivial.

Note that, unlike other security updates for your system, merely installing the updated packages is not enough. One must also remove and regenerate all affected SSH and SSL keys. Depending on your setup, this could be a massive task. It will also be very disruptive to end users if you’re changing host SSH keys for example.

What’s affected:

• Any SSH or SSL keys generated on Debian Etch or recent Testing/unstable;
• Any SSH or SSL keys generated on all Debian-derived systems corresponding to “Debian Etch and later”: for Ubuntu, this means Feisty 7.04, Gutsy 7.10 and Hardy 8.04
• Any DSA-style SSH keys used on a system with a vulnerable host key, even if the keys themselves are not vulnerable.

What you need to do:

• Get the updated openssl and openssh packages on to your system. Debian and Ubuntu’s openssh package includes a check on the SSH host key and also includes a tool to check user keys. Where possible, run ssh-vulnkey -a as root to check all users’ keys and authorized_keys for the vulnerable ones;
• If you generated any other SSL keys, such as for HTTP/SSL certificates, figure out when they were generated and whether the system was running Etch or later at the time. If so, these should be considered compromised and regenerated. As far as I can tell at the moment, there is no automated tool for checking SSL keys and ceritificates

The dust has finally settled on this one here, I hope, and this is what I found:

• At work, all our servers were originally installed as Debian Sarge and so none of the host SSH keys were vulnerable, even though the systems themselves are now running Etch;
• No vulnerable SSH user keys (apart from one that I created solely for the purpose of seeing whether it could be detected by the vulnerability scanner: it could), since hardly any of us use them and those of us that do had generated them during the Sarge era: being rather sluggish upgrading from Sarge to Etch actually helped here!
• No vulnerable SSL keys for our external sites: they were all made a while ago;
• About a dozen vulnerable SSL keys on internal servers: these will need to be replaced, but as exposure to these is limited, that’s less of a risk;
• At home: main PC has evolved from Ubuntu Dapper 6.06 and so has keys generated before this problem arose; my laptop was installed as a pre-release Ubuntu Hardy 8.04, but I never put openssh-server on it, so no vulnerability there. Also, the home partition was inherited from an earlier release and the user keys were not vulnerable either; the fileserver was installed as Etch and had a vulnerable host key, which has been regenerated. And my newly-acquired Asus Eee (more about that in a later post!), which is based on Xandros which is derived from Debian, appears to have a vulnerable version of the SSL code installed, because the key I generated on it was identified by the vulnerability scanner on another system.

As Bruce Schneier once said (I think): “Bad crypto looks just like good crypto”

Updated 15 May 2008: It has occurred to me this morning that all systems which support SSH are potentially at risk here, not just Debian-based ones. For instance, any system which has an uploaded weak user key is vulnerable to that user account being easily cracked, regardless of the OS which that system runs. e.g. if I generate a (weak) key on a Debian system and then upload the public part of the key to an OpenBSD server, then that OpenBSD server is vulnerable. All systems running SSH should probably check for these vulnerable keys: Debian and Ubuntu have released patches to reject vulnerable keys: I trust we’ll see the same thing for other OSes too.