On a multi-user machine where Alice can write to some arbitrary .git/ directory, she may be able to trick Bailey into executing arbitrary code by writing a .git/config like this:
[fs] monitor = evil.exe
...and convincing Baley to execute a git command (perhaps even via PS1 prompt configuration) in the directory containing the malicious .git/.
Git config is not cloned, so Alice can't upload a poisoned Git project and just get the victim to clone it over the internet -- Alice must perform the attack locally on a machine Bailey has access to.
I personally don't live in a world where multi-user escalation is relevant (and Phabricator usually won't, either) and think this isn't too many layers shy of "Alice may write an evil Makefile and trick Bailey into executing arbitrary code by running make in a directory Alice controls", but obviously it's strictly more severe.
Impact on Phabricator/Phacility
Broadly, this has no direct impact on Phabricator, except that the mitigation is for Git to refuse to run when the repository is owned by another user, and this is a common Phabricator configuration (the directory is owned by the "repository user", while the "web user" may run some commands -- but see below).
In particular, this is the Phacility configuration and Ubuntu 20 has patched itself to include the backwards-compatibility-breaking Git mitigation without operator intervention and without a version number change. All parts of this are a bit perplexing to me -- I'd generally prefer my system not break itself undetectably without operator intervention.
Possible fixes may be:
- We shouldn't really (?) be running on repositories as two different users -- we're always supposed to "sudo" to the repository user -- so maybe this is an actual bug in Phabricator where some pathways are just missing the "sudo" wrapper?
- Or maybe add --config safe-directories=/path/to/target to every command to just bypass the fix.
See also PHI2188.