The latest OpenSSH update, OpenSSH 7.1p2, disabled experimental client-side roaming support to address a serious information leak flaw. The issue would have let an attacker who had successfully compromised a server to steal credentials from individual clients.
Since version 5.4, the OpenSSH client has had an undocumented feature for resuming SSH connections, aka roaming. If the client's connection to an SSH server broke unexpectedly and the server supported roaming, the feature would let the client reconnect and resume the interrupted SSH session. Though the corresponding server code was never shipped, roaming was enabled by default in the client code.
"Server side was disabled/gutted for years already, but this aspect was surprisingly forgotten. Thanks for the report from Qualys," according to a commit message posted on OpenSSH's GitHub page.
All versions of OpenSSH, from version 5.4 to 7.1, are affected, except for OpenSSH 6.6, according to a post by Qualys Security, which discovered both CVE-2016-0777 and CVE-2016-0778. While the information leak may already have been exploited in the wild, the attack scenario is fairly limited since attackers can't simply set up a fake SSH server and trick users into connecting. Instead, they'd have to compromise SSH servers the users are already connecting to. However, if those clients have keys for other SSH accounts stored in memory, the attacker on the compromised SSH server gets them all.
"While such an attack would be difficult to pull off -- the attacker would have to already have compromised an SSH server already trusted by the victim -- the bug could be leveraged to impersonate the victim on SSH servers that the attacker has not yet compromised," said Tod Beardsley, the security research manager at Rapid7.
How the keys are leaked
CVE 2016-0777 is an information leak (memory disclosure) that can be exploited by a rogue SSH server to trick a client into leaking sensitive data from client memory. Passphrase-encrypted SSH keys are leaked in their encrypted form, so those keys aren't exposed, though there is nothing stopping an attacker from cracking those keys using other methods. The authentication of the server host key prevents exploitation by a man-in-the-middle attack, so this information leak is restricted to connections to malicious or compromised servers.
Qualys noted that SSH keys available only through an authentication agent are never leaked "in any form."
At first, Qualys researchers believed the leak would not allow a malicious SSH server to steal the client's private keys because of the way memory was being freed. It turned out that was not the case because the private key remained in the buffers for various functions, even if the actual memory location was freed. While there are many reasons why the private key could be leaked, the fact that one of the functions used to load the key resulted in internal stdio buffering, was the most severe, Qualys said.
"GNU/Linux is not affected because the
glibc mmap()s and
mumap()s and therefore cleanses stdio buffers. BSD-systems, on the other hand, are severely affected because they simply
free() stdio buffers," Qualys said in its description of the bug.
Fixes and workarounds
Fixed versions are or will shortly be available for most affected operating systems. Debian, Ubuntu, Red Hat Enterprise Linux, and other distributions have already made the new OpenSSH client available in their repositories. Fixed versions are also available for OpenBSD snapshots dated 2016-01-12 and later, OpenBSD 5.7-stable, and OpenBSD 5.8-stable.
For systems that cannot be patched immediately, there is a workaround to 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 the client vulnerability from being exploited.
High-profile sites and users concerned they may have been targeted should regenerate their SSH keys.
Other issues are low-risk
CVE 2016-0778 is a buffer overflow (heap-based) that can also be exploited by a rogue SSH server, but is likely exploitable under certain nondefault conditions, such as using ProxyCommand, ForwardAgent (-A), or ForwardX11 (-X). The flaw is "unlikely to have any real-world impact, but provides a particularly interesting case study," Qualys said.
Other security issues fixed in OpenSSH include a fix an out-of-bound read access in the packet handling code and a fix to stop untrusted X11-forwarding on the X server to fallback to trusted forwarding.