A bug that leaks Private cryptographic keys has been found and patched in the OpenSSH client, one of the most-used implementations of the secure shell protocol, according to an official advisory.

SSH makes sure all data passing over the wire is encrypted. It also provides host authentication, meaning that it verifies if the Server you are talking to is genuine, while making sure no one can control that session.

What happened?

The affected code resides in OpenSSH client versions 5.4 to 7.1, in a default feature called roaming. By storing the current Ssh Session in the computer’s RAM memory, this feature allows the restart of an SSH session if the connection has been interrupted for various reasons.

The code contains a memory disclosure (CVE-2016-0777) and a buffer overflow vulnerability (CVE-2016-0778). By exploiting them, a maliciously configured server could force the disclosure of client memory to the server, including Private Keys.

Private keys are important because they provide a more secure way to log into a server than using a passwords. The SSH server uses the public key to “lock” messages in a way that can only be deciphered by the private key stored on the client computer. So, cyber-criminals who can secretly grab private keys can log into other systems.

Exploitation consequences

Open SSH warns that the vulnerability may have already been exploited in the wild by sophisticated attackers and advises site owners and users to regenerate their SSH keys.

Fortunately, exploitation is not at hand and depends on several circumstances.

 This flaw can’t be exploited remotely, and tricking someone that uses the OpenSSH client in connecting to a compromised one is pretty difficult,” says Bogdan Botezatu, Senior E-Threat Analyst at Bitdefender. “Yes, the consequences are serious, but the attack avenues are fortunately quite limited.”

As for systems affected by the flaw, Ubuntu, versions 12.04, 1404, 15.04, and 15.10 are on the list.

Fixes

The OpenSSH team has released client version 7.1p2 that fixes the issue. So, immediate patching solves the problem.

For systems that cannot be patched immediately, there is a workaround. Add the UseRoaming option to the configuration file. Either add UseRoaming no to ssh_config or restart the SSH client with -oUseRoaming=no option to prevent exploitation of the client vulnerability.

Is this a new type of Heartbleed? Could it disrupt the Internet as we know it? We just have to wait and see.