I wonder if SSH agent forwarding exposes private keys to remote SSH client. After reading man ssh_config, it seems that only the agent interface is exposed, not the keys themselves.

In this post, I will summarize fixes for certain server environments.

The CVEs are CVE-2016-0777 and CVE-2016-0778.

Quick fix

The vulnerable code (for Roaming) can be disabled in SSH client settings:
Just drop

UseRoaming no

In the SSH client config file.

A critical bug that can leak secret cryptographic keys has just just been fixed in OpenSSH, one of the more widely used implementations of the secure shell (SSH) protocol.

The vulnerability resides only in the version end users use to connect to servers and not in versions used by servers. A maliciously configured server could exploit it to obtain the contents of the connecting computer’s memory, including the private encryption key used for SSH connections. The bug is the result of code that enables an experimental roaming feature in OpenSSH versions 5.4 to 7.1

“The matching server code has never been shipped, but the client code was enabled by default and could be tricked by a malicious server into leaking client memory to the server, including private client user keys,” OpenSSH officials wrote in an advisory published Thursday. “The authentication of the server host key prevents exploitation by a man-in-the-middle, so this information leak is restricted to connections to malicious or compromised servers.”

The advisory said that anyone using a vulnerable version should update right away. Those who are unable to update should disable roaming by adding the string UseRoaming no to the global ssh_config(5) file or to the user configuration

Qualys Security Advisory
Roaming through the OpenSSH client: CVE-2016-0777 and CVE-2016-0778

Since version 5.4 (released on March 8, 2010), the OpenSSH client
supports an undocumented feature called roaming: if the connection to an
SSH server breaks unexpectedly, and if the server supports roaming as
well, the client is able to reconnect to the server and resume the
suspended SSH session.

Although roaming is not supported by the OpenSSH server, it is enabled
by default in the OpenSSH client, and contains two vulnerabilities that
can be exploited by a malicious SSH server (or a trusted but compromised
server): an information leak (memory disclosure), and a buffer overflow
(heap-based).

The information leak is exploitable in the default configuration of the
OpenSSH client, and (depending on the client’s version, compiler, and
operating system) allows a malicious SSH server to steal the client’s
private keys. 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.

The buffer overflow, on the other hand, is present in the default
configuration of the OpenSSH client but its exploitation requires two
non-default options: a ProxyCommand, and either ForwardAgent (-A) or
ForwardX11 (-X). This buffer overflow is therefore unlikely to have any
real-world impact, but provides a particularly interesting case study.

All OpenSSH versions between 5.4 and 7.1 are vulnerable, but can be
easily hot-fixed by setting the undocumented option “UseRoaming” to
“no”, as detailed in the Mitigating Factors section. OpenSSH version
7.1p2 (released on January 14, 2016) disables roaming by default.

Private Key Disclosure
————————————————————————

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, because:

- the information leaked is not read from out-of-bounds memory, but from
a previously free()d chunk of memory that is recycled to malloc()ate
the client’s roaming buffer out_buf;

- private keys are loaded from disk into memory and freed by key_free()
(old API, OpenSSH = 6.7),
and both functions properly cleanse the private keys’ memory with
OPENSSL_cleanse() or explicit_bzero();

- temporary copies of in-memory private keys are freed by buffer_free()
(old API) or sshbuf_free() (new API), and both functions attempt to
cleanse these copies with memset() or bzero().

Mitigating Factors
————————————————————————

This information leak affects all OpenSSH clients >= 5.4, but its impact
is slightly reduced by the following four reasons:

1. The vulnerable roaming code can be permanently disabled by adding the
undocumented option “UseRoaming no” to the system-wide configuration
file

2. If an OpenSSH client is disconnected from an SSH server that offers
roaming, it prints “[connection suspended, press return to resume]” on
stderr, and waits for ‘\n’ or ‘\r’ on stdin (and not on the controlling
terminal) before it reconnects to the server; advanced users may become
suspicious and press Control-C or Control-Z instead, thus avoiding the
information leak:

3. Although a man-in-the-middle attacker can reset the TCP connection
between an OpenSSH client and an OpenSSH server (which does not support
roaming), it cannot exploit the information leak without breaking server
host authentication or integrity protection

In conclusion, an attacker who wishes to exploit this information leak
must convince its target OpenSSH client to connect to a malicious server
(an unlikely scenario), or compromise a trusted server (a more likely
scenario, for a determined attacker).

4. We discovered several non-security bugs, in specific versions and
configurations of OpenSSH, that prevent the client’s roaming code from
reconnecting to the server and, as a result, prevent this information
leak from being exploited.

This is the most serious bug you’ll hear about this week: the issues identified and fixed in OpenSSH are dubbed CVE-2016-0777 and CVE-2016-0778.
An early heads up came from Theo de Raadt in this mailing list posting.
Until you are able to patch affected systems, the recommended workaround is to use

UPDATE: This affects OpenSSH versions 5.4 through 7.1.
UPDATE: The following commit from deraadt@ has just gone in:
CVSROOT: /cvs
Module name: src
Changes by: deraadt@cvs.openbsd.org 2016/01/14 07:34:34

Modified files:
usr.bin/ssh : readconf.c ssh.c

Log message:
Disable experimental client-side roaming support. Server side was
disabled/gutted for years already, but this aspect was surprisingly
forgotten. Thanks for report from Qualys

USN-2869-1: OpenSSH vulnerabilities
http://www.ubuntu.com/usn/usn-2869-1/

Details
It was discovered that the OpenSSH client experimental support for resuming
connections contained multiple security issues. A malicious server could
use this issue to leak client memory to the server, including private
client user keys.

Since version 5.4 (released on March 8, 2010), the OpenSSH client
supports an undocumented feature called roaming: if the connection to an
SSH server breaks unexpectedly, and if the server supports roaming as
well, the client is able to reconnect to the server and resume the
suspended SSH session.

Although roaming is not supported by the OpenSSH server, it is enabled
by default in the OpenSSH client, and contains two vulnerabilities that
can be exploited by a malicious SSH server (or a trusted but compromised
server): an information leak (memory disclosure), and a buffer overflow
(heap-based).

The information leak is exploitable in the default configuration of the
OpenSSH client, and (depending on the client’s version, compiler, and
operating system) allows a malicious SSH server to steal the client’s
private keys. 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.