Git Repository Vulnerability Causes Remote Code Execution Attacks

A serious vulnerability, which could cause remote code execution attacks has been detected and then patched in the Git software source code. The patching of this vulnerability has helped prevent such attacks that were being launched at users.

Git is an open source software that has originally been created for Linux Kernel development and which is used to manage source code repositories, tarballs, and to track changes in files.

Edward Thomson, program manager for Visual Studio Team Services at Microsoft, discusses this vulnerability, CVE 2018-11235, in detail in a blog post. The blog post, dated May 29, 2018, and titled ‘Remediating the May 2018 Git Security Vulnerability‘ says- “The Git community has disclosed an industry-wide security vulnerability in Git that can lead to arbitrary code execution when a user operates in a malicious repository. This vulnerability has been assigned CVE 2018-11235 by Mitre, the organization that assigns unique numbers to track security vulnerabilities in software.”

In a detailed post on this Git repository vulnerability, ZDNet explains what the vulnerability exactly is; the ZDNet blog post says- “The vulnerability, CVE 2018-11235, occurs due to the management of remote repository definitions and data. Remote repositories may contain definitions for submodules — and data — which are contained and checked in to the parent repository as a folder. When this repository is cloned, Git checks the parent system before preparing to clone related submodules. As the submodule’s repository already exists on disk, full cloning is skipped and the software will only check the on-disk version. When you use Git to clone a repository, some configuration elements are also intentionally left out to prevent remote servers from fetching and executing code on remote systems. Some of the configurations left out including the content of the .git/config file and hook scripts. The vulnerability, however, allows exactly this to happen.”

Edward Thomson explains further-“Since the submodule’s repository is checked in to the parent repository, it’s never actually cloned. The submodule repository can therefore actually have a hook already configured. If when you recursively cloned this carefully crafted malicious parent repository, it will first check out the parent, then read the submodule’s checked-in repository in order to write the submodule to the working directory, and finally it will execute any post-checkout hooks that are configured in the submodule’s checked-in repository.”

The vulnerability, which proved to be industry-wide, was promptly resolved in the latest update of the Git software. Microsoft has sought to mitigate the vulnerability by endeavoring to block malicious repositories from being pushed to VSTS.

While the credit for finding the bug and also finding the proof of concept from which the test script was adapted has been given to Etienne Stalmans, the credit for fixing it (and another bug as well) goes to Jeff King, Johannes Schindelin etc.