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
option and one of
or
.
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
to
or your user’s
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.
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.
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.
Heiko
An undocumented feature which is by default “on” looks very professional m(