The developers behind Git and various companies providing Git repository hosting services have pushed out a fix to patch a dangerous vulnerability in the Git source code versioning software.
The fix is included with Git 2.17.1, which patches two security bugs, CVE-2018-11233 and CVE-2018-11235.
Git flaw leads to arbitrary code execution on users' PCs
Of these, CVE-2018-11235 is considered the most dangerous, as it allows a malicious actor to create a malformed Git repository containing a specially-built Git submodule.
Whenever a user clones this repository, because of the way Git clients handle this malicious Git submodule may allow an attacker to execute code on users' systems.
Git 2.17.1, released last night, should prevent the execution of these commands on users' computers.
Server-side fixes provided for Git hosting services
But patches aren't only rolled out to Git clients. A fix is also included for Git's server-side component. This server-side fix allows Git hosting services to recognize code repositories containing malicious submodules, and block users from uploading them in the first place.
Git hosting services like GitHub and Microsoft (via its Visual Studio Team Services) have already deployed the patches to prevent attackers from abusing their services.
"This is actually where most of the work went," said Jeff King, a GitHub staff member. "The fix itself was pretty trivial, but detection during [Git push operations] required a lot of refactoring."
King said the work involved many projects. "I wrote the patches for Git itself, but others worked on libgit2, JGit, and VSTS," he added.
Edward Thomson, Program Manager for Visual Studio Team Services, has also provided a more technical explanation of CVE-2018-11235:
A remote repository may contain a definition for a submodule, and also bundle that submodule’s repository data, checked in to the parent repository as a folder. When recursively cloning this repository, git will first checkout the parent repository into the working directory, then prepare to clone the submodule. It will then realize that it doesn’t need to do the clone – the submodule’s repository already exists on disk; since it was checked in to the parent, it was written to the working directory when it was checked out. Therefore git can skip the fetch and simply check out the submodule using the repository that’s on disk.
The problem is that when you
git clone a repository, there is some important configuration that you don’t get from the server. This includes the contents of the
.git/config file, and things like hooks, which are scripts that will be run at certain points within the git workflow. For example, the
post-checkout hook will be run anytime git checks files out into the working directory.
This configuration is not cloned from the remote server because that would open a dangerous vulnerability: that a remote server could provide you code that you would then execute on your computer.
Unfortunately, with this submodule configuration vulnerability, that’s exactly what happens. 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 (and this repository does have to be cloned with
--recursive for this vulnerability to manifest) 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.
Credit for the discovery of this vulnerability goes to Etienne Stalmans, who reported it via GitHub's bug bounty program.
Thomson provides additional instructions for testing if users run vulnerable Git clients on his blog. Users are advised to update their Git desktop and/or server clients.