The bug is the result of an undocumented feature called “roaming” that exists in version 5.4, released March 8, 2010, and above.
It’s one of two vulnerabilities that a malicious SSH server or a trusted but compromised server can exploit, Qualys said. The other is a heap-based buffer overflow.
OpenSSH issued a fix for the information leak Thursday.
About the Flaws
Depending on the version of the OpenSSH client used, the compiler and the OS, the information leak can let a malicious or compromised SSH server steal the client’s private keys, Qualys said.
If a server supports roaming and the connection to the server breaks unexpectedly, roaming lets the client reconnect and resume the suspended SSH session.
The OpenSSH server doesn’t support roaming, but it is enabled by default in the OpenSSH client.
The leak already may have been exploited in the wild, Qualys suggested.
The buffer overflow also is present in the default configuration of the OpenSSH client, but exploiting it requires two nondefault options — a ProxyCommand and SSH Forward Agent, either ForwardAgent (-A) or ForwardXll (-X), Qualys said. As a result, the buffer overflow is unlikely to have any real-world impact.
How the Information Leak Works
The openSSH client’s roaming_write() function is a simple wrapper around write(), Qualys said. It calls wait_for_roaming_reconnect() to transparently reconnect to the SSH server after a disconnection. It also calls buf_append() to copy the data sent to the server into the roaming buffer out_buf. When there’s a reconnection, the client can resend the data that wasn’t received by the server when the connection broke.
A malicious server has to massage the client’s heap before roaming_reply() malloc()ates out_buf, and force malloc() to return a previously free()d but uncleansed chunk of information.
The server also has to guess the client’s get_snd_buf_size.
It has to advise the client’s resend_bytes() that all available bytes — the entire out_buf_size — are needed by the server, even if fewer bytes were actually written by the client to the server.
“The ability to steal private key files from an SSH client is a big deal,” said Craig Young, cybersecurity researcher forTripwire.
“Users connecting to untrusted servers need to be aware that key material on their system may have been exposed to server operators,” he told LinuxInsider.
Mitigating the Impact
However, there are several ways to reduce the impact of the information leak, including permanently disabling the vulnerable roaming code by adding the undocumented option “UseRoaming no” to the system-wide or per-user configuration files, according to Qualys.
Further, the company has discovered several nonsecurity bugs in specific versions and configurations of OpenSSH that prevent the client’s roaming code from reconnecting to the server.
The flaws are not dangerous, security consultantSorin Mustaca said.
“In order to exploit this vulnerability, an attacker must convince its target OpenSSH client to connect to a malicious server — an unlikely scenario — or compromise a trusted server and install a special build of the OpenSSH server having roaming activated,” he told LinuxInsider. The second option “is possible but also unlikely to happen.”
If hackers compromise a server to the degree that they can replace OpenSSH, for which they need root access, “it would be better for them to insert their own private keys and have access to the server directly rather than stealing someone else’s private key,” Mustaca remarked. Even if a private key is stolen, the thief has to figure out where else it’s being used.
Fixing the Problem
OpenSSH fixed the information leak flaw with the release of v7.1p2 of the client. The flaw also has been corrected in OpenBSD’s stable branch.
In earlier versions of the client, the problem can be hot-fixed easily by setting the undocumented option “UseRoaming” to “no.”
“OpenSSH did very well by fixing these issues,” Mustaca observed.