A critical remote code execution vulnerability has been discovered in the git clone which was assigned with CVE-2024-32002 and the severity has been given as 9.0 (Critical).
This particular vulnerability existed in the clone command that is widely used.
Git released a security advisory last week which stated that about a Remote Code Execution.
In addition to this, the vulnerability was described to be existing due to the submodules that can be drafted in a particular way that could result in remote code execution.
However, this vulnerability has been fixed by git and patched versions have been released.
According to the reports shared with Cyber Security News, git employs submodules which are repositories nested within other repositories.
Every submodule has a designated directory path within the main directory which is tracked for ensuring changes are recorded accurately.
On observing further, it was discovered that there were case-insensitive filesystems in the default settings on Windows (A/modules/x) and macOS (a/modules/x).
Both of these paths are treated the same which is the main core reason behind the remote code execution.
In addition to this, symlinks or symbolic links are file system objects that act as pointers to other files or directories.
However, this symlink can be used for referencing other parts of the repository making it exploitable for malicious purposes.
ANYRUN malware sandbox’s 8th Birthday Special Offer: Grab 6 Months of Free Service
Source Code Analysis
As per the commit of the fix of this vulnerability, there were changes only to two files which were builtin/submodule–helper.c and t/t7406-submodule-update.sh.
Additionally, the message on the commit indicated that “On case-insensitive filesystems, however, we blindly replace a directory that has been created as part of the clone operation with a symlink when the path to the latter differs only in case from the former’s path…..we must be careful not to follow symbolic links.
Otherwise we may follow a symbolic link pointing to a gitdir (which are valid symbolic links!) e.g. while cloning.”
builtin/submodule–helper.c file and t/t7406-submodule-update.sh
The change on this file contained the clone_submodule which handles the cloning process for submodules.
There was a new function dir_contains_only_dotgit which checks if a directory contains only a .git file or directory.
Further, the clone_submodule was added with a Git check to determine whether the submodule directory exists or is empty.
In case of empty, the operation is aborted to avoid overwriting. Whereas the t/t7406-submodule-update.sh is a test script that has multiple information like Global configuration, hook repository setup, and main repository setup.
Exploitation Of The RCE
With all the information, the root issue existed in the case-insensitive filesystems treating paths like A/modules/x and a/modules/x as identical.
To exploit this, a malicious symlink must be crafted within the submodule, which is named with a case variation of the submodule’s path, but at the end, it points to the .git/ directory.
When a victim clones the malicious repository, Git creates a directory for the submodule, which is supplied with a symlink that makes the malicious symlink to be replaced in the newly created directory.
If the script is crafted in a different way, it could lead to executing remote code on the vulnerable instance system.
A proof of concept has been published by the researcher, which can be triggered using the following command:
git clone –recursive [email protected]:amalmurali47/git_rce.git
.webp "Git Vulnerability Let Attackers Execute Remote Code 1")
.webp "Git Vulnerability Let Attackers Execute Remote Code 2")
Free Webinar on Live API Attack Simulation: Book Your Seat | Start protecting your APIs from hackers