CVE 2018-11235 is a new industry-wide security vulnerability in Git that can lead to arbitrary code execution when a user operates in a malicious repository. In the announcement, Edward Thomson describes the vulenerability:
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 clonea repository, there is some important configuration that you don’t get from the server. This includes the contents of the
.git/configfile, and things like hooks, which are scripts that will be run at certain points within the git workflow. For example, the
post-checkouthook 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
--recursivefor 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-checkouthooks that are configured in the submodule’s checked-in repository.
Thanks to SSXIO for the hat tip.