Change Details

On a multi-user machine where Alice can write to any `.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.

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.

On a multi-user machine where Alice can write to any `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.