Page MenuHomePhabricator

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

Authored by epriestley on Aug 11 2017, 12:16 AM.
Referenced Files
F13308470: D18389.diff
Mon, Jun 10, 4:06 AM
F13281204: D18389.diff
Sun, Jun 2, 9:51 AM
F13251048: D18389.id44202.diff
Fri, May 24, 7:39 PM
F13247945: D18389.diff
Thu, May 23, 11:47 PM
F13244539: D18389.diff
Thu, May 23, 5:07 AM
F13236202: D18389.diff
Tue, May 21, 8:43 AM
F13234655: D18389.diff
Tue, May 21, 3:37 AM
F13181086: D18389.id44200.diff
May 9 2024, 8:17 AM



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

rP Phabricator
Lint Not Applicable
Tests Not Applicable