Adjusting to OpenSSH client "Roaming" vulnerability

A bug in OpenSSH client (versions 5.4 through 7.1) has been announced yesterday. The devs and distribution maintainers forgot to remove some experimental code. Malicious server can take advantage of this and make the client leak memory, possibly exposing its private keys. Theoretically, the issue only concerns environments from where you ssh. In practice we use deploy keys on certain servers - we clone code to them over git and SSH transport (automated integration tests, jenkins CI).

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: in /etc/ssh/ssh_config globally, or ~/.ssh/config for current user. Just drop

UseRoaming no

In the SSH client config file.

OS X

If you ssh from you Mac, you should do the quick fix mentioned above, and wait for OpenSSH client update.

Ubuntu, Debian

On Ubuntu Trusty, the openssh-client version should be at least 1:6.6p1-2ubuntu2.4. More in here.

On Debian Jessie at least 1:6.7p1-5+deb8u1, Wheezy 1:6.0p1-4+deb7u3. More in here.

Check your installed version with

dpkg --list | grep openssh-client

To update it, do:

$ sudo apt-get update && apt-get install -y openssh-client

CoreOS

The fix is in 899.3.0 (https://coreos.com/releases/). In case it didn't make it to CoreOS stable channel at the time of reading do the quick fix.

CentOS

TLDR: Do nothing.

CentOS won by not playing. From the CVE: this affects OpenSSH versions 5.4 through 7.1. On CentOS 6 after aggressive update:

$ rpm -qa | grep ssh
openssh-clients-5.3p1-112.el6_7.x86_64

Docker images

If you have a Docker image that uses SSH client (perhaps as a transport for Git client), you might want to update it as well. It then depends on what is your image based on. If you indeed use SSH client in a Docker container, the image is most likely based on some popular distro (Ubuntu, Debian, CentOS or better: Alpine).

When you read this, the distribution have already updated their SSH client package in their official Docker images (as long as the release is still maintained). To get it into your image, you should pull, rebuild and check the version. To illustrate with an image called "appimg". To rebuild:

$ cd appimg-dir
$ docker build -t appimg --pull --no-cache ./

To check the version:

# for debian/ubuntu-based images
$ docker run --rm appimg dpkg --list openssh-client
# for CentOS-based images
$ docker run --rm appimg-centos rpm -qi openssh-clients
# for Alpine
$ docker run --rm appimg-alpine apk info openssh-client

It's clear that if your application image is not based directly on a distro image, you need to rebuild the intermediate images in correct order.

There is also a nice doc from Digital Ocean on the topic.