OpenSSH vulnerability could expose private credentials

There’s nothing as jarring for a sysadmin as seeing this kind of message on a mailing list:

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.

OpenSSH “roaming” vulnerability

So what exactly does this announcement mean? Since OpenSSH client version 5.4, there has been a feature called roaming that allows the client to resume a session that has been interrupted. Both the server and client would need to support roaming for this to work.

Server support was never added, but the feature is on by default for OpenSSH clients up to version 7.1p2. There are two vulnerabilities that stem from this feature and could be exploited when a user connects to an “evil” SSH server.

Private keys could be leaked

The first — and scariest — vulnerability is an information disclosure that could leak your SSH private key to the malicious server. To exploit this, the malicious server would ask for a resend (part of the roaming feature) of more data than was actually written. The client then reads potentially uncleansed memory and sends it to the server.

OpenSSH buffer overflow

The second vulnerability is a buffer overflow in the client. This is much less likely to be exploited because it requires both the relatively uncommon

ProxyCommand

option and one of

ForwardAgent

or

ForwardX11

.

In either case, there isn’t a possibility for a man-in-the-middle style attack, so only connections to malicious or compromised hosts would be a potential vector.

Patching OpenSSH

To mitigate both of these vulnerabilities, add

UseRoaming no

to

/etc/ssh/ssh_config

or your user’s

~/.ssh/config

file. When a fix is available for your OS, update your OpenSSH client as soon as possible. For more detailed information about the vulnerability, see the Qualys Security report and get updates on undeadly.org.

An update is currently awaiting testing for Fedora at the time of publishing. Within the next day, the package should be submitted to the stable repositories and begin appearing on Fedora repository mirrors.

For Developers For System Administrators

3 Comments

  1. Cornel Panceac

    Now, after the fact, it’s obvious that enabling only the client-side of the feature was not a good idea. One has to wonder if there are also other such half-implemented things that are enabled by default. Not necessarily limited to OpenSSH, of course.

  2. arehtykitna

    I’ve never bothered with OpenSSH, in fact I remove the startup program entries for the client and service from MATE and remove the packages from my systems anyhow. I also disable Spice and have never noticed any ill effects from doing so.

    There is no reason to have something I don’t use running. Seeing articles such as this just goes to prove it is even more prudent to remove unwanted remote access tools.

  3. Heiko

    An undocumented feature which is by default “on” looks very professional m(

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions