Summary

This issue exists because of an incomplete fix forCVE-2023-40590. On Windows, GitPython uses an untrusted search path if it uses a shell to rungit, as well as when it runsbash.exe to interpret hooks. If either of those features are used on Windows, a maliciousgit.exe orbash.exe may be run from an untrusted repository.

Details

Although GitPython often avoids executing programs found in an untrusted search path since 3.1.33, two situations remain where this still occurs. Either can allow arbitrary code execution under some circumstances.

When a shell is used

GitPython can be told to rungit commands through a shell rather than as direct subprocesses, by passingshell=True to any method that accepts it, or by both settingGit.USE_SHELL = True and not passingshell=False. Then the Windowscmd.exe shell process performs the path search, and GitPython does not prevent that shell from finding and runninggit in the current directory.

When GitPython runsgit directly rather than through a shell, the GitPython process performs the path search, and currently omits the current directory by settingNoDefaultCurrentDirectoryInExePath in its own environment during thePopen call. Although thecmd.exe shell will honor this environment variable when present, GitPython does not currently pass it into the shell subprocess's environment.

Furthermore, because GitPython sets the subprocess CWD to the root of a repository's working tree, using a shell will run a maliciousgit.exe in an untrusted repository even if GitPython itself is run from a trusted location.

This also applies ifGit.execute is called directly withshell=True (or afterGit.USE_SHELL = True) to run any command.

When hook scripts are run

On Windows, GitPython usesbash.exe to run hooks that appear to be scripts. However, unlike when runninggit, no steps are taken to avoid finding and runningbash.exe in the current directory.

This allows the author of an untrusted fork or branch to cause a maliciousbash.exe to be run in some otherwise safe workflows. An example of such a scenario is if the user installs a trusted hook while on a trusted branch, then switches to an untrusted feature branch (possibly from a fork) to review proposed changes. If the untrusted feature branch contains a maliciousbash.exe and the user's current working directory is the working tree, and the user performs an action that runs the hook, then although the hook itself is uncorrupted, it runs with the maliciousbash.exe.

Note that, whilebash.exe is a shell, this is a separate scenario from whengit is run using the unrelated Windowscmd.exe shell.

PoC

On Windows, create agit.exe file in a repository. Then create aRepo object, and call any method through it (directly or indirectly) that supports theshell keyword argument withshell=True:

mkdir testrepogit init testrepocp ... testrepo\git.exe# Replace "..." with any executable of choice.python-c"import git; print(git.Repo('testrepo').git.version(shell=True))"

Thegit.exe executable in the repository directory will be run.

Or use noRepo object, but do it from the location with thegit.exe:

cd testrepopython-c"import git; print(git.Git().version(shell=True))"

Thegit.exe executable in the current directory will be run.

For the scenario with hooks, install a hook in a repository, create abash.exe file in the current directory, and perform an operation that causes GitPython to attempt to run the hook:

mkdir testrepocd testrepogit initmv .git/hooks/pre-commit.sample .git/hooks/pre-commitcp ...bash.exe# Replace "..." with any executable of choice.echo"Some text">file.txtgit add file.txtpython-c"import git; git.Repo().index.commit('Some message')"

Thebash.exe executable in the current directory will be run.

Impact

The greatest impact is probably in applications that setGit.USE_SHELL = True for historical reasons. (Undesired console windows had, in the past, been created in some kinds of applications, when it was not used.) Such an application may be vulnerable to arbitrary code execution from a malicious repository, even with no other exacerbating conditions. This is to say that, if a shell is used to rungit, the full effect ofCVE-2023-40590 is still present. Furthermore, as noted above, running the application itself from a trusted directory is not a sufficient mitigation.

An application that does not direct GitPython to use a shell to rungit subprocesses thus avoids most of the risk. However, there is no such straightforward way to prevent GitPython from runningbash.exe to interpret hooks. So while the conditions needed for that to be exploited are more involved, it may be harder to mitigate decisively prior to patching.

Possible solutions

A straightforward approach would be to address each bug directly:

• When a shell is used, passNoDefaultCurrentDirectoryInExePath into the subprocess environment, because in that scenario the subprocess is thecmd.exe shell that itself performs the path search.
• SetNoDefaultCurrentDirectoryInExePath in the GitPython process environment during thePopen call made to run hooks with abash.exe subprocess.

These need only be done on Windows.