Git released new versions that address 5 new vulnerabilities

git vulnerability

Git, the source code control system distributed, has been affected by a series of vulnerabilities, of which, one of them is classified with a critical severity level, since it allows the execution of malicious code by cloning a repository manipulated by an attacker using the "git clone" command.

In order to solve recent vulnerabilities, Git version 2.45.1 was released, which addresses five critical vulnerabilities affecting Windows, macOS, Linux, and BSD.

Critical vulnerabilities in Git

The new corrective versions of Git ranging from version 2.45.1 to 2.39.4 and solve the five vulnerabilities, being the most serious of these vulnerabilities (CVE-2024-32002) which occurs only in file systems that are case-insensitive and support symbolic links, such as those used by default in Windows and macOS.

This time, we therefore added more changes that not only fix existing security issues but also attempt 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 execute harmful code on your computer.

It is mentioned that the problem occurs when creating a directory and symbolic link in the submodule, differing only in the use of upper and lower case characters, allowing files to be written to the .git/ directory instead of the submodule's working directory. By gaining the ability to write in .git/, an attacker can modify the hooks through .git/hooks and execute arbitrary code during a «"git clone".

Hen/Stag other vulnerabilities that were fixed are:

  • CVE-2024-32004 (“High” severity level): On multi-user machines, an attacker can prepare a local repository to appear as a partial clone with an object missing, so that when this repository is cloned, Git will execute arbitrary code during the operation with full permissions of the user performing the clone .
  • CVE-2024-32465 (“High” severity level): Cloning from .zip files containing Git repositories can bypass protections, potentially allowing insecure hooks to be executed. There are circumstances where fixes for CVE-2024-32004 are not sufficient. For example, when obtaining a .zip file containing a full copy of a Git repository, it should not be relied upon to be secure by default, since, for example, links could be configured to run within the context of that repository.
  • CVE-2024-32020 (“Low” severity level): When the 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 linked files can be rewritten at any time by that other user, which can easily surprise users who are not familiar with this implementation detail.
  • CVE-2024-32021 (“Low” severity level): When cloning a local source repository that contains symbolic links, Git can create hard links in the directory objects / to arbitrary files on the same file system as the target repository. This can be used in sophisticated attacks to manipulate Git to write files outside of the Git working tree and outside of the directory. .git/.

It is worth mentioning that in addition to correcting the vulnerabilities, the new versions They also introduce several changes aimed at improving protection against vulnerabilities that lead to remote code execution and manipulation of symbolic links when cloning. Paths to submodules can now only contain actual directories.

Additionally, it has been published a detailed analysis of the technique to exploit the vulnerability CVE-2024-32002 and an example of an exploit that allows creating repositories that, when cloned with the command «git clone --recursive«, they execute the code specified by the attacker.

If you are interested in knowing more about it, you can consult the details In the following link.


Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: Miguel Ángel Gatón
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.