A vulnerability within Git has been recently announced concerning the case-insensitive nature of the Windows file system. This vulnerability is unique in that fact that an attacker does have the ability to execute arbitrary code, however conventional exploitation methods, such as memory corruption, is not required. This article explores two ways to execute arbitrary, attacker controlled code on a remote system. First, we take a look at GitHub For Windows and how hook scripts can be executed. Then, we dive into Visual Studio 2013, which as of this writing is still unpatched.
GitHub For Windows Vulnerability
According to the GitHub advisory, an attacker “can craft a malicious Git tree that will cause Git to overwrite its own .git/config file when cloning or checking out a repository, leading to arbitrary command execution in the client machine.” So how does an attacker go from simply overwriting a directory to executing arbitrary code…remotely? A typical .git directory contains a very interesting sub-directory named hooks:
This hooks sub-directory stores scripts which are automatically executed whenever a particular git command is issued. For example, the file named pre-commit will execute prior to issuing a git commit command. What’s even more interesting is that these scripts can be written in any scriptable language, such as perl which is bundled with GitHub For Window’s console application. This allows for extremely complex and dangerous payloads to be executed. Note: for an entire listing of which hook scripts are available, the githooks man page provides detailed information.
Taking a look at the patch diff:
We see that the return values for a couple new functions are assigned to the has_dotgit variable. Digging into the is_ntfs_dotgit() function, we see that a case comparison is done against the .git and git~1 strings.
So it appears that there are two attack vectors that can be taken in order to exploit this vulnerability. One, taking advantage of the case insensitive nature of the windows and MAC OS X operating systems, and two, taking advantage of Window’s 8.3 file naming convention.
Before exploiting this vulnerability, it’s important to note that a client and server each have their own .git directory. So when the client victim clones the malicious repository, their .git directory is overwritten with the malicious .git directory structure, containing the attack payload.
In this example, the malicious attack server will be hosted on a case-sensitive operating system – Kali Linux. Because of this case-sensitive nature, we are able to create two separate directories, .git and .Git:
And hidden within the .Git/hooks directory, lies the malicious perl script (which, in this case, launches Windows calculator):
Next, the changes are committed and the server daemon is launched:
The victim, running a vulnerable version of GitHub For Windows, then clones the repo:
And commits any changes they’ve made, executing the malicious payload:
Microsoft Visual Studio 2013 Vulnerability – A Slightly Different Approach
While the official GitHub clients have been patched to resolve the issue, other implementations of git over Windows (or Mac) may still be affected - one such implementation is Microsoft Visual Studio 2013.
Visual Studio 2013 suffers from essentially the same case-insensitive vulnerability, however, one caveat is that client side hooks are disabled. As such, this will not allow us to execute scripts in the same manner. However, as with most other things, when there is a will there is a way - and it this case, there is definitely a way.
Another very interesting file within the .git directory is the config file. This file specifies different options for various git functionality. For instance, we can specify which diff tool Visual Studio will use to display any file differences between the local and remote repository:
In this config file, we are defining the diff tool to be “sometool” and specifying the path to the tool’s location on the local (victim) file system. An attacker can leverage the case-insensitive vulnerability by placing a malicious executable inside the .Git directory which will be ran whenever a diff is performed within Visual Studio 2013, which we’ll now show in greater detail.
First we upload a malicious executable to the .Git directory:
Then we modify the config file to point to this location on disk:
Note: here we can provide a relative file path. In this case, .git is implicitly specified.
And finally, these changes are committed and the malicious daemon is hosted.
On the client side of things, we fire up Visual Studio 2013 and clone the malicious repo:
We then modify a file and do a comparison:
Which finally executes our payload within the .git directory:
In conclusion, it is important not to limit our outlook based on an advisory. It was stated that “…libgit2 (and Visual Studio which uses it) have been updated at the same time.” Yet, this is not the case. We can see that when developers introduce vulnerable code into their own software, multiple applications can be affected while flying under the radar. Although this vulnerability does require an attacker-controlled repository, limiting the chance of exploitation, we still hope to see this vulnerability within Visual Studio fixed in the near future.
This hooks sub-directory stores scripts which are automatically executed whenever a particular git command is issued. For example, the file named pre-commit will execute prior to issuing a git commit command. What’s even more interesting is that these scripts can be written in any scriptable language, such as perl which is bundled with GitHub For Window’s console application. This allows for extremely complex and dangerous payloads to be executed. Note: for an entire listing of which hook scripts are available, the githooks man page provides detailed information.
Taking a look at the patch diff:
We see that the return values for a couple new functions are assigned to the has_dotgit variable. Digging into the is_ntfs_dotgit() function, we see that a case comparison is done against the .git and git~1 strings.
So it appears that there are two attack vectors that can be taken in order to exploit this vulnerability. One, taking advantage of the case insensitive nature of the windows and MAC OS X operating systems, and two, taking advantage of Window’s 8.3 file naming convention.
Before exploiting this vulnerability, it’s important to note that a client and server each have their own .git directory. So when the client victim clones the malicious repository, their .git directory is overwritten with the malicious .git directory structure, containing the attack payload.
In this example, the malicious attack server will be hosted on a case-sensitive operating system – Kali Linux. Because of this case-sensitive nature, we are able to create two separate directories, .git and .Git:
And hidden within the .Git/hooks directory, lies the malicious perl script (which, in this case, launches Windows calculator):
Next, the changes are committed and the server daemon is launched:
The victim, running a vulnerable version of GitHub For Windows, then clones the repo:
And commits any changes they’ve made, executing the malicious payload:
Microsoft Visual Studio 2013 Vulnerability – A Slightly Different Approach
While the official GitHub clients have been patched to resolve the issue, other implementations of git over Windows (or Mac) may still be affected - one such implementation is Microsoft Visual Studio 2013.
Visual Studio 2013 suffers from essentially the same case-insensitive vulnerability, however, one caveat is that client side hooks are disabled. As such, this will not allow us to execute scripts in the same manner. However, as with most other things, when there is a will there is a way - and it this case, there is definitely a way.
Another very interesting file within the .git directory is the config file. This file specifies different options for various git functionality. For instance, we can specify which diff tool Visual Studio will use to display any file differences between the local and remote repository:
In this config file, we are defining the diff tool to be “sometool” and specifying the path to the tool’s location on the local (victim) file system. An attacker can leverage the case-insensitive vulnerability by placing a malicious executable inside the .Git directory which will be ran whenever a diff is performed within Visual Studio 2013, which we’ll now show in greater detail.
First we upload a malicious executable to the .Git directory:
Then we modify the config file to point to this location on disk:
Note: here we can provide a relative file path. In this case, .git is implicitly specified.
And finally, these changes are committed and the malicious daemon is hosted.
On the client side of things, we fire up Visual Studio 2013 and clone the malicious repo:
We then modify a file and do a comparison:
Which finally executes our payload within the .git directory:
In conclusion, it is important not to limit our outlook based on an advisory. It was stated that “…libgit2 (and Visual Studio which uses it) have been updated at the same time.” Yet, this is not the case. We can see that when developers introduce vulnerable code into their own software, multiple applications can be affected while flying under the radar. Although this vulnerability does require an attacker-controlled repository, limiting the chance of exploitation, we still hope to see this vulnerability within Visual Studio fixed in the near future.
