This is now in master so I've made the task public.

I don't want to leave RCE in Phabricator for 3 weeks, so I'm planning to land, deploy and disclose some version of the patch above today.

(I change visibility for this to @epriestley, @amckinley and @durin42 for now -- note that I intend to eventually make this issue public once the fix hits the commit log, so don't stockpile all your 0-days here.)

I missed your question in (1). A typical scenario for this would be when working on a feature which requires some refactoring work to be done. A revision is created with just the refactoring work and then a dependent revision is made which includes the actual feature work. During feature work additional refactoring might be made and need to update to that changeset and either add/amend changes, rebase the dependent revision back on top. Having the bookmarks auto created would help especially when using arc:bookmark when updating revisions back to phab.

In T9548#229910, @indygreg wrote:

https://www.mercurial-scm.org/repo/hg/file/default/contrib/phabricator.py is a Mercurial extension that allows you to send a series of changesets to Phabricator by calling Conduit APIs directly. The extension is currently tailored for the use cases of the Mercurial project itself, isn't distributed with Mercurial, and may require Mercurial 4.3. And it obviously bypasses Phabricator's built-in Mercurial server. But if you are willing to live with the caveats, you may find it a suitable workaround.

See also PHI45.

The behavior may have changed, but the change is from "we sometimes silently do the wrong thing" to "we explicitly refuse to do the wrong thing".

Ah, it sounded like a regression from the report. I haven't tried to bisect to determine if that was true.

That is, specifically, it expected that hg commands do not work in Phabricator if it can not determine the version of hg, so this is not a bug. Ignoring the setup warning might mean "we used to do Mercurial stuff but don't anymore, leaving us with some archived Mercurial repositories which we don't really need to look at, so it's okay that hg commands won't be able to run".

The version is strictly required because different versions of hg use different command syntax. If we can not determine which version of hg is installed, we can not run hg commands.

There doesn't seem to be anything actionable remaining on our end.

This cropped up in the HN thread -- works in my browsers (although Phabricator does not recognize it as a valid link):

Thanks for the writeup :)

The reason the upstream projects aren't using -- is that it isn't portable. For example, Putty's ssh doesn't support it.

The full set of mitigations is now available in stable, and I've promoted 2017 Week 32 (Mid August).

See also this enormously valuable contribution I made to the Git LFS upstream in connection with T7789 some time ago:

In T12961#230931, @avivey wrote:

So, all three major VCS had the exact same CVE, which was "we invoke ssh command line, don't sanitize input, and don't specify -- anywhere"?

Thanks for the detailed explanations! I should have thought more carefully. Note old Mercurial also fails to do correct shell quoting on Windows (It uses ' where Windows needs "). But Phabricator does not run on Windows, it shouldn't be an issue.

So, all three major VCS had the exact same CVE, which was "we invoke ssh command line, don't sanitize input, and don't specify -- anywhere"?

@indygreg Thanks for the heads up about subrepos -- I would not have otherwise guessed that hg pull might run git.

From this writeup:

The magic incantation I arrived at was slightly modified from one of the hg test cases:

Never mind, I was able to get hg pull -u to interact. I'm going to land, cherry-pick, and hotfix D18390.

I think this is related:
https://www.mercurial-scm.org/wiki/Subrepository#Synchronizing_in_subrepositories

And here's an extension which appears to be aimed at solving this problem, by adding a new command to execute hg pull -u in subrepositories:

Also, although ui.ssh appears inneffective against the [git] and [svn] variants of subrepos (Mercurial does not appear to populate GIT_SSH or SVN_SSH based on the ui.ssh setting), I can't get hg to actually interact with remotes using hg clone --noupdate ... or hg pull -u -- <uri>, which are the only relevant commands we run. I can get it to interact with remotes with hg up or hg clone (without --noupdate).

In the example above, I put malicious content in .hgsub, like this:

The subrepo issue is when .hgsub has malicious content (ex. foo = ssh://-oProxyCommand=touch%20BAR/). It's not related to command line or config files.

I'm going to cherry-pick rP794e185bf90e (the SSH wrapper stuff) to stable and hotfix production, although I'm not entirely certain hg pull -u -- <uri> is vulnerable.

I also can't get hg pull -u -- <uri> to fetch subrepos, am I just not setting things up correctly? In my current working state, hg up tries to interact with the subrepo remote but hg pull -u -- <uri> (which is what we actually execute) does not.

See also T4416. Removing -u hasn't been a priority because no actual install has expressed interest in it.

That same code I pointed to for Mercurial also seems to perform Git working copy checkouts. Although I can't recall Git's semantics for automatically updating submodules (because I don't use them). It is worth auditing.

Note that Phabricator can manifest Mercurial working directories. See executeMercurialUpdate() in src/applications/repository/engine/PhabricatorRepositoryPullEngine.php. It does this when pulling non-hosted repos. I know this occurs when observing repos. Not sure where else this code is used.

I'll leave this open until I write up the release notes since it deserves a mention (users are still vulnerable if an attacker tricks them into running a suspicious git clone command), but I think we're otherwise unscathed by this.

We also used to have a separate PhutilGitURI which had looser rules, but I removed this in D16100 (June 13, 2016) and all URI parsing now goes through PhutilURI which has the stricter rules.

The theoretical attack here is:

These are slightly more fleshed-out versions of the attack in Mercurial:

git, svn, and hg... wow

The attack is basically:

oh wow

https://www.mercurial-scm.org/repo/hg/file/default/contrib/phabricator.py is a Mercurial extension that allows you to send a series of changesets to Phabricator by calling Conduit APIs directly. The extension is currently tailored for the use cases of the Mercurial project itself, isn't distributed with Mercurial, and may require Mercurial 4.3. And it obviously bypasses Phabricator's built-in Mercurial server. But if you are willing to live with the caveats, you may find it a suitable workaround.

This is pretty sad that this bug is still open. I haven't found a way to use Phabricator with recent Mercurial, so I'm sticking on 4.0.1 ATM.

Parsing hg export metadata is an elegant solution. # HG changeset patch could imply sourceControlSystem = 'hg'. Thanks for merging the task!

That sounds like a bug, but my guess is that the investigation would probably turn up "wow you are dumb at writing software" in about 3 minutes and not really get us much closer to a fix, which is probably "rewrite arc patch to fix 200 problems".

For (1), it's currently expected, yes. We don't create branches for dependencies in Git either, currently. I don't think this is terribly unreasonable, but I'm also not sure it's terribly useful (does it just help you keep track of which commits are part of the leaf?) and it makes cleanup more difficult by creating more total branch/bookmark artifacts in the local working copy.

Also, I've noticed that when applying dependent revisions like this, it seems that usually all of the commits will apply cleanly (without prompting) except for the last one, which will always fail to locate the commit to apply on and prompt whether to apply to current working copy state. Based on what I think arcanist is doing I would expect all patches to prompt whether to apply to working copy (since all patches will be given new commit IDs) -- it seems strange that all will apply cleanly except the last one. Does that sound like a bug or am I misunderstanding what's happening? I can try to investigate/debug if you think it might be a bug.

For (1), it is expected to not apply bookmarks to dependency changesets that are applied as part of the patch issued? When patched one-by-one they would each obtain their bookmark.

(That is, our behavior seems clearly incorrect.)

This just looks unambiguously wrong to me.

Some of the (3), (2), (1) stuff is that we're trying to pick a single behavior which addresses most use cases reasonably well. For example, if we use "natural" bookmark names that will tend to make things much worse for users in bucket (3).

My solution to this problem was to compile version 3.4.2 of mercurial and install with a different PREFIX, and only use it for pushing to phabricator. That way I can use the latest version of mercurial for everything else.

I'm just going to nuke this since there's no repro. This workflow has also been rewritten on the experimental branch and the specific error encountered here should now be impossible.

I can confirm T12129 is indeed related, and the suggested workaround is very effective. Thanks for this!
For the record, our repo has about 60 branches total (about a dozen active only).

See Planning for information on timelines and priorities.

Just curious if there is any news on this front?

What if you try recreating the output generated by the hg commands shown from the --trace -- does the output look off in any way?

Did that, you can see the result at P2054. At least to me, nothing looks fishy...

Any weird environment variables defined on those workstations? Also add --trace to the arc diff command might give more details

Just tried it, didn't help :(

What if you disable the extdiff extension? The documentation doesn't mention modifying regular diff output but probably worth trying.

We have installed mercurial 3.9.2 both in the server and client, in fact we downgraded the client mercurial from 4.1 to 3.9.2 to match the versions, but nothing changed. The version of arcanist is 3c4735795a29 (pre-last commit) and phabricator is at ef839192aa5a (from Tuesday).

Please identify the versions of mercurial used on client/server, also the version of Phabricator in use. If you're on an older version of Phabricator it's possible that upgrading may resolve the issue.

Also this should probably be using ui.status()/ui.warn() instead of print.

Yes. We'd retain the base revision information during parsing in differential.createrawdiff, and it would remain available later in arc patch.

@epriestley - Just to clarify, with the solution you're suggesting that would mean the diff created using differential.createrawdiff → differential.revision.edit would result in arc patch of that revision applying the patch to the base revision parsed from the raw diff from hg log --patch --rev <rev>?

Oh, you're right. I misread an implication of implementation specifics into "set", but the actual language doesn't actually suggest an implementation.

I tried to not specifically ask for a change to API or parsing, just that the missing bit I need is a base revision set on the new diff.

↑ I second @rros, commenting line line 71 of the PhabricatorRepositoryRefEngine class fixed it for me. Don't know about possible secondary effect but I have the feeling it was not working as intended anyway.