Update dependency GitPython to v3.1.41 [SECURITY] #56
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
==3.1.30
->==3.1.41
GitHub Vulnerability Alerts
CVE-2023-40267
GitPython before 3.1.32 does not block insecure non-multi options in
clone
andclone_from
, making it vulnerable to Remote Code Execution (RCE) due to improper user input validation, which makes it possible to inject a maliciously crafted remote URL into the clone command. Exploiting this vulnerability is possible because the library makes external calls to git without sufficient sanitization of input arguments. NOTE: this issue exists because of an incomplete fix for CVE-2022-24439.CVE-2023-40590
Summary
When resolving a program, Python/Windows look for the current working directory, and after that the PATH environment (see big warning in https://docs.python.org/3/library/subprocess.html#popen-constructor). GitPython defaults to use the
git
command, if a user runs GitPython from a repo has agit.exe
orgit
executable, that program will be run instead of the one in the user'sPATH
.Details
This is more of a problem on how Python interacts with Windows systems, Linux and any other OS aren't affected by this. But probably people using GitPython usually run it from the CWD of a repo.
The execution of the
git
command happens inhttps://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/cmd.py#L277
https://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/cmd.py#L983-L996
And there are other commands executed that should probably be aware of this problem.
PoC
On a Windows system, create a
git.exe
orgit
executable in any directory, and import or run GitPython from that directoryThe git executable from the current directory will be run.
Impact
An attacker can trick a user to download a repository with a malicious
git
executable, if the user runs/imports GitPython from that directory, it allows the attacker to run any arbitrary commands.Possible solutions
C:\\Program Files\\Git\\cmd\\git.EXE
(default git path installation).GIT_PYTHON_GIT_EXECUTABLE
environment variable on Windows systems.GIT_PYTHON_GIT_EXECUTABLE
env var to an absolute path.PATH
environment variable (suggested by @Byron)Note
This vulnerability was reported via email, and it was decided to publish it here and make it public, so the community is aware of it, and a fix can be provided.
CVE-2024-22190
Summary
This issue exists because of an incomplete fix for CVE-2023-40590. On Windows, GitPython uses an untrusted search path if it uses a shell to run
git
, 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 run
git
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 runs
git
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 malicious
git.exe
in an untrusted repository even if GitPython itself is run from a trusted location.This also applies if
Git.execute
is called directly withshell=True
(or afterGit.USE_SHELL = True
) to run any command.When hook scripts are run
On Windows, GitPython uses
bash.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 malicious
bash.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, while
bash.exe
is a shell, this is a separate scenario from whengit
is run using the unrelated Windowscmd.exe
shell.PoC
On Windows, create a
git.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
:The
git.exe
executable in the repository directory will be run.Or use no
Repo
object, but do it from the location with thegit.exe
:The
git.exe
executable in the current directory will be run.For the scenario with hooks, install a hook in a repository, create a
bash.exe
file in the current directory, and perform an operation that causes GitPython to attempt to run the hook:The
bash.exe
executable in the current directory will be run.Impact
The greatest impact is probably in applications that set
Git.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 of CVE-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 run
git
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:
NoDefaultCurrentDirectoryInExePath
into the subprocess environment, because in that scenario the subprocess is thecmd.exe
shell that itself performs the path search.NoDefaultCurrentDirectoryInExePath
in the GitPython process environment during thePopen
call made to run hooks with abash.exe
subprocess.These need only be done on Windows.
CVE-2023-41040
Summary
In order to resolve some git references, GitPython reads files from the
.git
directory, in some places the name of the file being read is provided by the user, GitPython doesn't check if this file is located outside the.git
directory. This allows an attacker to make GitPython read any file from the system.Details
This vulnerability is present in
https://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/refs/symbolic.py#L174-L175
That code joins the base directory with a user given string without checking if the final path is located outside the base directory.
I was able to exploit it from three places, but there may be more code paths that lead to it:
https://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/repo/base.py#L605
https://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/repo/base.py#L620
https://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/index/base.py#L1353
PoC
Running GitPython within any repo should work, here is an example with the GitPython repo.
Impact
I wasn't able to show the contents of the files (that's why "blind" local file inclusion), depending on how GitPython is being used, this can be used by an attacker for something inoffensive as checking if a file exits, or cause a DoS by making GitPython read a big/infinite file (like
/dev/random
on Linux systems).Possible solutions
A solution would be to check that the final path isn't located outside the
repodir
path (maybe even after resolving symlinks). Maybe there could be other checks in place to make sure that the reference names are valid.Release Notes
gitpython-developers/GitPython (GitPython)
v3.1.41
: - fix Windows security issueCompare Source
The details about the Windows security issue can be found in this advisory.
Special thanks go to @EliahKagan who reported the issue and fixed it in a single stroke, while being responsible for an incredible amount of improvements that he contributed over the last couple of months ❤️.
What's Changed
__all__
in git.exc by @EliahKagan in https://github.com/gitpython-developers/GitPython/pull/17198ec2390
toec58b7e
by @dependabot in https://github.com/gitpython-developers/GitPython/pull/1722New Contributors
Full Changelog: gitpython-developers/GitPython@3.1.40...3.1.41
v3.1.40
: - fix downstream CICompare Source
What's Changed
Full Changelog: gitpython-developers/GitPython@3.1.38...3.1.40
v3.1.38
Compare Source
What's Changed
49c3178
to8ec2390
by @dependabot in https://github.com/gitpython-developers/GitPython/pull/17048ec2390
to6a22706
by @dependabot in https://github.com/gitpython-developers/GitPython/pull/1705New Contributors
Full Changelog: gitpython-developers/GitPython@3.1.37...3.1.38
v3.1.37
: - a proper fix CVE-2023-41040Compare Source
What's Changed
@NoEffect
annotations by @EliahKagan in https://github.com/gitpython-developers/GitPython/pull/1677Full Changelog: gitpython-developers/GitPython@3.1.36...3.1.37
v3.1.36
Compare Source
v3.1.35
: - a fix for CVE-2023-41040Compare Source
What's Changed
New Contributors
Full Changelog: gitpython-developers/GitPython@3.1.34...3.1.35
v3.1.34
: - fix resource leakingCompare Source
What's Changed
New Contributors
Full Changelog: gitpython-developers/GitPython@3.1.33...3.1.34
v3.1.33
: - with security fixCompare Source
What's Changed
New Contributors
Full Changelog: gitpython-developers/GitPython@3.1.32...3.1.33
v3.1.32
: - with another security updateCompare Source
What's Changed
New Contributors
Full Changelog: gitpython-developers/GitPython@3.1.31...3.1.32
v3.1.31
Compare Source
What's Changed
command -v
instead of third-partywhich
program by @mgorny in https://github.com/gitpython-developers/GitPython/pull/1525New Contributors
Full Changelog: gitpython-developers/GitPython@3.1.30...3.1.31
Configuration
📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.