Hi there, Git users!

Today, I write to you not in my capacity as Git for Windows maintainer, but as the Git community coordinator of the latest security bugfix release of Git.

In the ever-evolving landscape of software development, security remains a paramount concern, especially for the Git project. Alongside our other business priorities, we hold the fort when it comes to safeguarding your work. It’s with this unwavering commitment to security that we bring to your attention the latest Git version, v2.45.1, released on May 14, 2024, which addresses not one but five vulnerabilities. Affected platforms are Windows, macOS, Linux, and even *BSD, so these fixes are important for everyone! 😊 This release is coordinated with Visual Studio and GitHub Desktop, which include a subset of Git. We are also releasing several defense-in-depth updates to address themes that we have noticed in the past several bugfix releases.

• CVE-2024-32002 (Critical, Windows & macOS): Git repositories with submodules can trick Git into executing a hook from the.git/ directory during a clone operation, leading to Remote Code Execution.
• CVE-2024-32004 (High, multi-user machines): An attacker can craft a local repository that executes arbitrary code when cloned.
• CVE-2024-32465 (High, all setups): Cloning from.zip files containing Git repositories can bypass protections, potentially executing unsafe hooks.
• CVE-2024-32020 (Low, multi-user machines): Local clones on the same disk can allow untrusted users to modify hard-linked files in the cloned repository’s object database.
• CVE-2024-32021 (Low, multi-user machines): Cloning a local repository with symlinks can result in hard-linking to arbitrary files in theobjects/ directory.

Upgrading to the latest Git version is essential to protect against these vulnerabilities. If you cannot update immediately, please be careful from where you clone repositories.

Note: the defense-in-depth protection in this update causes a regression when cloning repositories enabled withGit LFS. The clone will fail with an error message. The remedy is to callgit lfs pull in the fresh clone.

Details

The main theme of these fixes is to improve the security of cloning Git repositories. It has long been Git’s stance that cloning even untrustworthy repositories should be a safe operation, and that it should be possible to “scrub” repositories of potentially malicious configurations and hooks—and in this release this is clearly documented.

Now, let’s dive into the details.

Recursive clones on case-insensitive filesystems that support symlinks are susceptible to Remote Code Execution (CVE-2024-32002, critical)

Repositories with submodules can be crafted in a way that exploits a bug in Git, whereby it can be fooled into writing files not into the submodule’s worktree but into a.git/ directory. This is possible by a combination of confusing Git with a directory and a symbolic link that differs only in case so that Git can write either one, or the other, but not both. This confusion can be used to manipulate Git into writing a hook that will be executed while the clone operation is still running, giving the user no opportunity to inspect the code that is being executed.

Remote Code Execution while cloning special-crafted local repositories (CVE-2024-32004, high)

On multi-user machines, an attacker can prepare a local repository so that it looks like a partial clone that is missing an object, so that, when this repository is cloned, Git will execute arbitrary code during the operation with full permissions of the user performing the clone.

Protections for cloning untrusted repositories can be bypassed (CVE-2024-32465, high)

There are circumstances where the fixes for CVE-2024-32004 are not enough. For example, when obtaining a.zip file containing a full copy of a Git repository, it should not be trusted by default to be safe, as for example, hooks could be configured to run within the context of that repository.

The Git project doesnot recommend for you to obtain Git repositories via.zip files containing a full copy of the worktree and.git/ directory!

Having said that, the Git project’s stance is that such an untrusted repository can be “sanitized” by cloning it locally, as is clarified in the Git documentation as part of this release. In such a scenario, Git is susceptible to the same manipulations as described in CVE-2024-32004.

Cloning local repository by untrusted user allows the untrusted user to modify objects in the cloned repository at will (CVE-2024-32020, low)

When source and target repository reside on the same disk, local clones may end up creating hard-links of files in the target repository’s object database. If the source repository is owned by a different user, this means that those newly hard-linked files may be rewritten at any point in time by that other user, which can easily come as a surprise to users who are unfamiliar with this implementation detail of Git.

Local clone may hard-link arbitrary user-readable files into the new repository’s “objects/” directory (CVE-2024-32021, low)

When cloning a local source repository that contains symbolic links, Git may create hard-links in theobjects/ directory to arbitrary files on the same filesystem as the target repository. This can be used in sophisticated attacks to manipulate Git into writing files outside the Git worktree and outside the.git/ directory.

Defense-in-depth

It has not escaped the Git project that there has been a common theme inthe vulnerabilities that have been fixed in previous security bugfix releases, as well as in this one: submodules support seems to be involved, and hooks escalate the severity of the found vulnerabilities to high or critical.

This time around, we therefore added more changes that not only fix existing security issues but also try to reduce the severity of any related vulnerabilities that may be found in the future:

• Git has introduced several security improvements to protect against Remote Code Execution (RCE), which is when an attacker could potentially run harmful code on your computer.
• These updates include better handling of symbolic links and directories during cloning operations to prevent Git from being tricked into writing files in the wrong places.
• Git now has a more secure way of running hooks, which are scripts that can run automatically during certain Git operations. This helps prevent unauthorized code from running during a clone.
• The configuration setting for the Git templates directory, which could influence which hooks run during a clone, is now protected to prevent accidental or malicious changes.
• Additionally, Git will now warn about symbolic links that point inside the.git/ directory, which could be a security risk. Users who want to be extra cautious can set these warnings to be treated as errors.

These changes are part of Git’s ongoing efforts to enhance security and ensure that the cloning process is safe from potential vulnerabilities.

Credits

CVE-2024-32002 andCVE-2024-32004 were found byFilip Heijsek and fixed byJohannes Schindelin. Apple Product Security foundCVE-2024-32020 andCVE-2024-32021, and they were fixed byPatrick Steinhardt.CVE-2024-32465 was found and fixed byJeff King. The defense-in-depth patches were contributed byJohannes Schindelin. Credit for in-depth reviews goes toJunio Hamano,Filip Hejsek,Johannes Schindelin, andPatrick Steinhardt.

Stay secure, stay updated, and let’s continue to build amazing software together.

Written by

Johannes Schindelin

@dscho

• Git
• security alert