Vulnerabilities

Remote Code Execution Vulnerability Patched in Git

Updates released on Tuesday for the Git version control system patch two security flaws, including a serious vulnerability that can be exploited for remote code execution using specially crafted repositories.

<p><strong><span><span>Updates released on Tuesday for the Git version control system patch two security flaws, including a serious vulnerability that can be exploited for remote code execution using specially crafted repositories.</span></span></strong></p>

Updates released on Tuesday for the Git version control system patch two security flaws, including a serious vulnerability that can be exploited for remote code execution using specially crafted repositories.

The security holes, tracked as CVE 2018-11235 and CVE 2018-11233, have been addressed with the release of Git v2.17.1, v2.13.7, v2.14.4, v2.15.2 and v2.16.4.

The more serious of them, CVE 2018-11235, is related to submodule names and recursively cloning repositories. The issue was discovered by Etienne Stalmans, who reported it through GitHub’s bug bounty program.

Microsoft’s Visual Studio Team Services (VSTS) team has provided some information about the vulnerability, instructions on how users can check if they are impacted, and the steps that need to be taken to mitigate the risks on each platform.

Edward Thomson, a program manager for Git in the Microsoft Visual Studio Team Service, has provided the following description for the vulnerability:

“When a Git repository contains a submodule, that submodule’s repository structure is stored alongside the parent’s, inside the .git folder. This structure is generally stored in a folder with the same name as the submodule, however the name of this folder is configurable by a file in the parent repository.


Vulnerable versions of git allow the folder name to contain a path that is not necessarily beneath the .git directory. This can allow an attacker to carefully create a parent repository that has another Git repository checked in, as a folder inside that parent repository. Then that repository that’s checked in can be added as a submodule to the parent repository. That submodule’s location can be set outside of the .git folder, pointing to the checked-in repository inside the parent itself.


Advertisement. Scroll to continue reading.

When you recursively clone this parent repository, Git will look at the submodule that has been configured, then look for where to store that submodule’s repository. It will follow the configuration into the parent repository itself, to the repository that’s been checked in as a folder. That repository will be used to check out the submodule… and, unfortunately, any hooks in that checked-in repository will be run.


So the attacker can bundle this repository configuration with a malicious post-checkout hook, and their code will be executed immediately upon your (recursive) clone of the repository.”

Microsoft, GitLab, GitHub and likely other Git hosting providers have taken steps to prevent abuse. However, users have still been advised to update their Git clients.

The second flaw is considered less serious. The issue is related to Git performing “path sanity-checks on NTFS that can be fooled into reading arbitrary memory.”

Related: Hackers Can Use Git Repos for Stealthy Attack on Developers

Related: Command Execution Flaw Affects Several Version Control Systems

Related: GitLab Patches Domain Hijacking Vulnerability

Related Content

Copyright © 2024 SecurityWeek ®, a Wired Business Media Publication. All Rights Reserved.

Exit mobile version