OpenSSH bug of the week

miTgiB

http://undeadly.org/cgi?action=article&sid=20160114142733

OpenSSH: client bug CVE-0216-0778
Contributed by tj on Thu Jan 14 15:41:37 2016 (GMT)
from the i-have-a-fviend-in-Vome dept.
This is the most serious bug you'll hear about this week: The issue dubbed CVE-0216-0778 has been identified and fixed in the OpenSSH.
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
# echo 'UseRoaming no' >> /etc/ssh/ssh_config

Traffic

More details: http://www.openssh.com/txt/release-7.1p2

SECURITY: ssh(1): The OpenSSH client code between 5.4 and 7.1

contains experimential support for resuming SSH-connections (roaming).

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.

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.

MITIGATION: For OpenSSH >= 5.4 the vulnerable code in the client

can be completely disabled by adding 'UseRoaming no' to the gobal
ssh_config(5) file, or to user configuration in ~/.ssh/config,
or by passing -oUseRoaming=no on the command line.

PATCH: See below for a patch to disable this feature (Disabling

Roaming in the Source Code).

This problem was reported by the Qualys Security Advisory team.

GM2015

debian got on it already:

Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  openssh-client openssh-server openssh-sftp-server
3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,161 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]

black

Updated. Thanks!

exception0x876

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.

So it is not so scary, is it?

perennate

exception0x876 said: So it is not so scary, is it?

The information leak can happen if you connect to any untrusted server. If you only connect to servers that you have already connected to it's okay, but e.g. someone can give you connection details and probably trick you into connecting (please help me install blah?).

jar

@perennate said:
The information leak can happen if you connect to any untrusted server. If you only connect to servers that you have already connected to it's okay, but e.g. someone can give you connection details and probably trick you into connecting (please help me install blah?).

A good reason to have a system you don't care about that you use to run "ssh -v" for diagnostics. I figured I was paranoid

GM2015

I use "-v" all the time, except when I forget it.

jarland said: A good reason to have a system you don't care about that you use to run "ssh -v" for diagnostics. I figured I was paranoid

lamron

Thanks for the heads up. I panicked a bit and updated everything I could and applied the workaround as well. Later I realized that it was the OpenSSH client that was affected. I never used it.

Neoon

jar

https://www.digitalocean.com/community/questions/openssh-client-bug-cve-2016-0777-and-cve-2016-0778

A little something Ryan put together for this. Quick mitigation against the issue