Malicious OpenSSH servers can silently steal people's private SSH keys as they try to login, it emerged today.
This means criminals who compromise one server can secretly grab keys needed to log into other systems from a user's computer – allowing crooks to jump from server to server.
The security cockup, present in the default configuration of OpenSSH, has been patched today, and all users and administrators are urged to update as soon as possible.
SSH keys are an alternative to passwords: you generate a public and private key pair, give the remote server your public key, and keep the private key on your own computer. Then when you next login, the SSH server and client use the keys to identify and authorize you. If someone swipes your private key, they can log in as you – it's as if they stole your password.
"When there's a serious security bug in the remote access tool used by 70-plus per cent of the servers in the world, people sit up and take notice," said Kenn White, co-director of the Open Crypto Audit Project.
The bug lies in versions 5.4 to 7.1 of the OpenSSH client, specifically in a little-known default-enabled feature called roaming that allows you to restart an SSH session after the connection has been interrupted. The roaming code contains an information sharing flaw (CVE-2016-0777) and a mildly harmless buffer overflow (CVE-2016-0778) blunder.
The experimental roaming feature is not supported by servers – but malicious or hacked systems could implement it server-side and exploit the info-leak vulnerability.
To cope with a connection break, the client keeps a buffer in memory that contains the user's private keys. According an excellent analysis by the flaw's finders Qualys, it is possible to extract the cryptographic data, either partially or completely.
"We initially believed that this information leak in the OpenSSH client's roaming code would not allow a malicious SSH server to steal the client's private keys," the Qualys team explained today.
"We eventually identified three reasons why, in our experiments, we were able to partially or completely retrieve the OpenSSH client's private keys through this information leak (depending on the client's version, compiler, operating system, heap layout, and private keys)."
Crucially, Qualys added:
This information leak may have already been exploited in the wild by sophisticated attackers, and high-profile sites or users may need to regenerate their SSH keys accordingly.
One bright spot is that passphrase-encrypted SSH keys are leaked in their encrypted form and must be cracked offline. Not everyone protects their keys using a passphrase, however.
The buffer overflow issue is less serious, since it can't be exploited in the default configuration of the OpenSSH client software. Instead it relies on the use of ProxyCommand, and either ForwardAgent (-A) or ForwardX11 and is unlikely to be exploited.
To kill off the client info-leak bug, patch your software, and add UseRoaming no to your SSH config files.
"For OpenSSH >= 5.4 the vulnerable code in the client can be completely disabled by adding 'UseRoaming no' to the global ssh_config(5) file, or to user configuration in ~/.ssh/config, or by passing -oUseRoaming=no on the command line," said the OpenSSH team in an advisory.
The OpenSSH team has released version 7.1p2 that fixes the issue and software houses are scrambling to lock down this latest threat. The latest builds of FreeBSD and OpenBSD have already been patched, as have Debian, Ubuntu, and Red Hat Enterprise Linux.
The problem is that it's now down to IT managers to make the necessary software upgrades, and as we've seen with Heartbleed that can take a while. In the meantime an attacker can either set up honeypot servers or (more likely) compromise existing legitimate OpenSSH servers, and start harvesting keys. ®
PS: 32-bit TLS servers written in Go need to be rebuilt because they may leak their private keys.