summaryrefslogtreecommitdiffstats
path: root/t/t1800-hook.sh
diff options
context:
space:
mode:
authorJohannes Schindelin <johannes.schindelin@gmx.de>2024-03-30 19:12:50 +0100
committerJohannes Schindelin <johannes.schindelin@gmx.de>2024-04-19 12:38:24 +0200
commit20f3588efc6cbcae5bbaabf65ee12df87b51a9ea (patch)
treef3121b1e7181c1a7f8fd2b5e8d1faf07342e87db /t/t1800-hook.sh
parentinit.templateDir: consider this config setting protected (diff)
downloadgit-20f3588efc6cbcae5bbaabf65ee12df87b51a9ea.tar.xz
git-20f3588efc6cbcae5bbaabf65ee12df87b51a9ea.zip
core.hooksPath: add some protection while cloning
Quite frequently, when vulnerabilities were found in Git's (quite complex) clone machinery, a relatively common way to escalate the severity was to trick Git into running a hook which is actually a script that has just been laid on disk as part of that clone. This constitutes a Remote Code Execution vulnerability, the highest severity observed in Git's vulnerabilities so far. Some previously-fixed vulnerabilities allowed malicious repositories to be crafted such that Git would check out files not in the worktree, but in, say, a submodule's `<git>/hooks/` directory. A vulnerability that "merely" allows to modify the Git config would allow a related attack vector, to manipulate Git into looking in the worktree for hooks, e.g. redirecting the location where Git looks for hooks, via setting `core.hooksPath` (which would be classified as CWE-427: Uncontrolled Search Path Element and CWE-114: Process Control, for more details see https://cwe.mitre.org/data/definitions/427.html and https://cwe.mitre.org/data/definitions/114.html). To prevent that attack vector, let's error out and complain loudly if an active `core.hooksPath` configuration is seen in the repository-local Git config during a `git clone`. There is one caveat: This changes Git's behavior in a slightly backwards-incompatible manner. While it is probably a rare scenario (if it exists at all) to configure `core.hooksPath` via a config in the Git templates, it _is_ conceivable that some valid setup requires this to work. In the hopefully very unlikely case that a user runs into this, there is an escape hatch: set the `GIT_CLONE_PROTECTION_ACTIVE=false` environment variable. Obviously, this should be done only with utmost caution. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Diffstat (limited to 't/t1800-hook.sh')
-rwxr-xr-xt/t1800-hook.sh15
1 files changed, 15 insertions, 0 deletions
diff --git a/t/t1800-hook.sh b/t/t1800-hook.sh
index 2ef3579fa7..7ee12e6f48 100755
--- a/t/t1800-hook.sh
+++ b/t/t1800-hook.sh
@@ -177,4 +177,19 @@ test_expect_success 'git hook run a hook with a bad shebang' '
test_cmp expect actual
'
+test_expect_success 'clone protections' '
+ test_config core.hooksPath "$(pwd)/my-hooks" &&
+ mkdir -p my-hooks &&
+ write_script my-hooks/test-hook <<-\EOF &&
+ echo Hook ran $1
+ EOF
+
+ git hook run test-hook 2>err &&
+ grep "Hook ran" err &&
+ test_must_fail env GIT_CLONE_PROTECTION_ACTIVE=true \
+ git hook run test-hook 2>err &&
+ grep "active .core.hooksPath" err &&
+ ! grep "Hook ran" err
+'
+
test_done