Page MenuHomePhabricator

Vulnerability Response: CVE-2016-0777/CVE-2016-0778
Closed, ResolvedPublic


Two vulnerabilities affecting SSH were partially disclosed this morning. There are some details here:

It seems like:

  • CVE-2016-0777: Worst case may be that when you SSH to a server, that server can read your private keys.
  • CVE-2016-0778: Worst case may be that when you SSH to a server, that server can execute arbitrary code on your client.

The key material compromise is not hugely concerning for Phabricator. In general, it would allow an attacker to do this:

  • Launch an evil server at
  • Configure Phabricator to connect to the server by adding it to Almanac/Drydock or configuring it as a remote repository.
  • Read their own private keys.

Because they generally only get access to their own keys, this isn't a huge deal, although it would potentially allow them to read keys from credentials stored in Passphrase that they could use but could not normally access.

The client execution issue is concerning, but it seems unlikely that we are affected given that it seems to require elaborate preconditions to be exploitable.

There is no particularly special impact of either issue to Phacility, as opposed to installs in general.

Because the particulars are still a bit murky and CVE-2016-0777 potentially allows sideways privilege escalation under certain conditions which isn't otherwise possible, I plan to apply the "UseRoaming no" configuration fix to the Phacility cluster.

Recommendation: Third-party installs should evaluate and mitigate this issue. This issue is serious and likely merits a response in almost all environments, but Phabricator is not specially impacted by it in a meaningful way.

Revisions and Commits

Related Objects

Event Timeline

epriestley added a commit: Restricted Diffusion Commit.Jan 14 2016, 5:10 PM

I've applied the configuration fix to all Phacility cluster hosts that initiate SSH connections to untrusted servers, so we should be in the clear.

(It will apply everywhere during the weekly deploy, but I think there's no need to disrupt services on, e.g., the db tier, which makes no outbound SSH requests, since they'll pick up the fix in less than 48 hours).

So far, I can't figure out how to verify that roaming is actually off or otherwise inspect the effective client configuration. I'll keep an eye out for such a method in discussion of the issue, but I suspect there may be no easy approach given that this feature was undocumented and apparently forgotten about.

A sufficient diagnostic test is apparently to complete any connection with ssh -v and observe no "Roaming not allowed by server" message in the output. Cluster hosts with the configuration fix pass this test.

The mitigation was applied to remaining nodes on Jan 16, and everything was also upgraded to OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.4, OpenSSL 1.0.1f 6 Jan 2014, which is the Ubuntu upstream fix for the issue.