TPS-2016-002 OpenSSH CVE-2016-0777 and CVE-2016-0778


Two new vulnerabilities in the OpenSSH SSH client (CVE-2016-0777 and CVE-2016-0778) allow a malicious or compromised SSH server to induce the client to leak arbitrary memory (including the client’s private keys), and, in some versions of the client, execute arbitrary code on the client system. The client checks the server’s host keys before reaching the point of vulnerability, so a man-in-the-middle attack is not a realistic vector (unless the server’s host keys have already been disclosed).

These vulnerabilities come about through a little-used feature of the client for “roaming” of connections, which has never been supported in the OpenSSH server, but for which client support was added in version 5.4.

Recent releases of SmartOS and SDC have included OpenSSH clients in the platform image (in /usr/bin) that are vulnerable to the first vulnerability (the information leak), but not the second (buffer overflow leading to arbitrary code execution). Apart from the SSH client in the platform image, within each SmartOS zone or VM running on the system there may be an SSH client installed manually by the user (e.g. from pkgsrc) that is vulnerable, potentially to both CVEs.

Checking for vulnerable versions

On your client, run the command ssh -V. If you see

OpenSSH_7.1p1, OpenSSL 1.0.1p 9 Jul 2015

and the number in the place where 7.1p1 appears above is between 5.4 and 7.1p1 inclusive, your client is vulnerable.

Immediate mitigation

There is a simple mitigation for both of these vulnerabilities that all users are encouraged to deploy immediately. Add the line

UseRoaming no

at the top of ~/.ssh/config (create the file if it does not already exist). Users may also add the commandline option -o 'UseRoaming no' to any invocation of the ssh command (the SSH client). This option entirely disables the vulnerable roaming feature that is the source of the issue.

Note: This configuration change will be rejected by and produce a fatal error when using SunSSH and OpenSSH versions older than 5.4, which are not vulnerable.


Users of Triton Elastic Container Infrastructure (formerly “SDC” or “SmartDataCenter”), or SmartOS releases between 20150917 and 20160108 (inclusive) should update their platform image to 20160121 as soon as possible after it is released. At this release, the upstream patch for this issue will be included (which simply disables the roaming feature). Users on a release older than 20150917 need not upgrade their platform image for this vulnerability, as it includes SunSSH (which is based on an OpenSSH version prior to 5.4, when the feature was introduced).

Users of LX-branded zones or KVMs with a vulnerable OpenSSH client installed should refer to their operating system’s or distribution’s announcements or project website for further details about when new packages will be available, and update accordingly.

Users of SmartOS zones who have installed openssh from pkgsrc versions 2014Q4 (LTS) and 2015Q3 will have updated packages made available soon and should update as soon as possible once released. If an upgrade is not possible, users should make use of the workaround described above, or perhaps consider building the SSH client from source if the need is particularly acute.


As before, please be assured that Joyent’s HTTPS endpoints for Manta, CloudAPI and our customer portal are not vulnerable.

Joyent customers who are using third-party operating systems are advised to contact their respective service providers for further information and instructions.

If you have followed the instructions above and further questions arise regarding mitigation of OpenSSH vulnerabilities (in Joyent products and services): Please contact Joyent Support by submitting a request at the support portal or by emailing