Security researchers have discovered a number of flaws in Git that could have enabled hackers to run remote code on a victim’s PC.
Git is version control system used for source code management in software development. According to a advisory by the Git community, a vulnerability, assigned CVE 2018-11235 by Mitre, the organisation that assigns unique numbers to track security vulnerabilities in software, could lead to arbitrary code execution when a user operates in a malicious repository.
The problem affects Git before 2.13.7, 2.14.x before 2.14.4, 2.15.x before 2.15.2, 2.16.x before 2.16.4, and 2.17.x before 2.17.1. According to an advisory by NIST, with a crafted .gitmodules file, a malicious project can execute an arbitrary script on a machine that runs “git clone –recurse-submodules” because submodule “names” are obtained from this file, and then appended to $GIT_DIR/modules, leading to directory traversal with “../” in a name.
“Finally, post-checkout hooks from a submodule are executed, bypassing the intended design in which hooks are not obtained from a remote server,” said the advisory.
In a more detailed account, Edward Thomson, program manager for Visual Studio Team Services, said that 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.
He said that the problem is that when someone clones a repository, there is some important configuration that they 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,” he said.
“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.”
Thomson added that 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,” he said.
“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.”
Thomson said that the solution to this problem is quite simple and effective: submodule’s folder names are now examined more closely by Git clients.
“They can no longer contain .. as a path segment, and they cannot be symbolic links, so they must be within the .git repository folder, and not in the actual repository’s working directory,” he said.
Another bug, CVE-2018-11233, could lead to reading random pieces of memory when running on an NTFS file-system.
The bug was first reported by Etienne Stalmans, who discovered the bug. Users are advised to update Git to v2.17.1 as soon as possible. More details on how to check for a vulnerable version and updates to affected versions can be found here.
David Rushmer, senior threat researcher at Cylance, told SC Media UK that beyond the creation of an internal Git repo, when using hosted instances such as Github, repositories come with certain control features.
“A “Private” repository controls who can see and commit to the repository. Should an organisation wish to make their code publicly available, the “Public” repository still offers control over who can merge code. It is possible to enforce code reviews as part of merge requests as well as enforcing multiple users to authorise a merge. While Git does not enforce workflows for managing Git repositories, designs such as GitFlow offer tried and tested methods that should help organisations better control their instances; by instilling users and admins with good working practices,” he said.
This article originally appeared on SC Media UK