Tasks related to enhancing the security of Phabricator.
Tue, Nov 21
That's a good point! I wish it was designed like that since the beginning. I guess it won't happen with the current compatibility rules since it is likely to break automation.
In theory, you could require --config appear between hg and foo in hg foo .... This is already a valid position for --config (for example, hg --config x=y foo is valid), and already not a valid position for foo flags (for example, hg --branch default log is not valid).
https://phab.mercurial-scm.org/D1483 should make it possible to use -- to defend non-flag user input. For inputs that are flags, use the form --flag=X and avoid --flag X.
Mon, Nov 13
We'll use the hardened mode once it's available, but I don't think we expect to take any further action here until then.
Fri, Nov 10
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.)
Oct 3 2017
Not a problem - thanks for fixing that so quickly.
I can confirm that fixed the issue for us.
Oct 2 2017
Sep 30 2017
(I'll fix this if you don't get there first, but have used up all my brain energy for today. And thanks for the report!)
Would it be acceptable to change PhutilRemarkupHyperlinkRule to catch this exception and behave as if it were a non-whitelisted protocol? (Happy to draft the patch, just want to check before I do so)
This change creates a slight problem for us at KDE as we have some historical commits in our Subversion repository which have URLs in them which are invalid. This exception means that:
- Herald spins forever trying to process these commits, failing every single time (currently up to 855 failures).
- The commit can't be viewed in the browser (See https://phabricator.kde.org/R883:271607)
Sep 29 2017
Sep 15 2017
Aug 22 2017
Aug 14 2017
There doesn't seem to be anything actionable remaining on our end.
Aug 12 2017
In https://hackerone.com/reports/259246 (not currently disclosed) a researcher found an actual issue with figlet. Although it would probably be hard to develop into a practical attack, it does make me feel better about the decision to pull all this stuff into PHP (not just dot) when the dot issue was originally identified.
Aug 11 2017
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:
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:
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: