Page MenuHomePhabricator

Pass SSH wrappers to VCS commands unconditonally, not just if there's an SSH remote
ClosedPublic

Authored by epriestley on Aug 11 2017, 12:16 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Dec 21, 3:15 PM
Unknown Object (File)
Fri, Dec 20, 11:28 AM
Unknown Object (File)
Fri, Dec 20, 10:47 AM
Unknown Object (File)
Fri, Dec 20, 4:25 AM
Unknown Object (File)
Sun, Dec 15, 2:05 PM
Unknown Object (File)
Tue, Dec 10, 11:54 PM
Unknown Object (File)
Tue, Dec 10, 4:00 AM
Unknown Object (File)
Tue, Nov 26, 11:48 PM
Subscribers

Details

Summary

Ref T12961. In Mercurial, it's possible to have "subrepos" which may use a different protocol than the main repository.

By putting an SSH repository inside an HTTP repository, an attacker can theoretically get us to execute hg without overriding ui.ssh, then execute code via the SSH hostname attack.

As an immediate mitigation to this attack, specify ui.ssh unconditionally. Normally, this will have no effect (it will just be ignored). In the specific case of an SSH repo inside an HTTP repo, it will defuse the ssh protocol.

For good measure and consistency, do the same for Subversion and Git. However, we don't normally maintain working copies for either Subversion or Git so it's unlikely that similar attacks exist there.

Test Plan
  • Put an SSH subrepo with an attack URI inside an HTTP outer repo in Mercurial.
  • Ran hg up with and without ui.ssh specified.
  • Got dangerous badness without ui.ssh and safe ssh subprocesses with ui.ssh.

I'm not yet able to confirm that hg pull -u -- <uri> can actually trigger this, but this can't hurt and our SSH wrapper is safer than the native behavior for all Subversion, Git and Mercurial versions released prior to today.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable