Git vulnerability with .gitconfig

Brian Harry

Today the Git community disclosed an issue in Git that, in the worst case, could allow a developer’s machine to be taken over.  This is an issue that manifests across much of the Git ecosystem and is not unique to Microsoft’s Git implementation or to Windows.  I’ll describe the problem and the steps we’ve taken to ensure our customers using Git repositories are protected against this issue. First, I want to thank the Hg (Mercurial) community for their help.  An analogous issue was discovered in Hg.  They took the time to look at Git and discovered that the same issue existed.  They carefully informed appropriate people in the community, shared information and controlled disclosure until preparations could be made to mitigate the issue.  It’s a great example of cooperation in the community.

The problem

Git has a file that it stores in your local GIt repository called config, in the .git folder.  This file contains a number of personal/preference settings.  Among them are aliases for git commands.  Using an alias, pretty much any git command can be repurposed to do anything you want. Normally the git client avoids ever overwriting that file.  Even if you commit a .git\config file and push it to a shared repo, no one else’s Git client will check it out into their private repos.  However, a bug was discovered where various permutations of the .git folder name (e.g. mixed case, gIT, GiT, etc, Windows filename shortening .git~123, Ignorable Unicode codepoints .g\u200cit\config, etc) were not caught be the Git client’s filtering logic.  As such, if someone pushed a malicious config file with one of these permutations, other people’s Git clients would check them out, overwriting their personal config file and hijacking their Git commands.  This affects, at least, Windows NTFS and Mac OS X HFS+ filesystems, both of which are case insensitive filesystems.

The risk

The risk is not quite as bad as it sounds.  For someone to do this to you, they have to have commit rights to a repo that you pull from.  Inside a corporation, that would likely have to be an attack from the inside.  The most likely (not only, but most likely) scenario here is in some small OSS project.  Large ones generally have pretty well known/trusted committers.  Further, as you’ll see below, steps have been take to mitigate this.

The fix

We and other members of the Git community have worked together to prepare for this issue becoming public.  I won’t speak for others but I know core Git and GitHub have both mitigated the issue.  I’ll talk concretely about steps we (Microsoft) have taken.

1. A week or so ago, we applied a patch both to VS Online and Codeplex that prevents the server from accepting pushes of .git\config files.  The bug really isn’t on the server (it’s in the client) but by doing this we reduce the possibility of any unpatched client from being exploited from one of our services.
2. We have prepared the same server fix for TFS 2013 (both RTM and Update 4).  TFS 2013 is the only TFS version that supports hosting Git repositories.  This will allow TFS administrators to take the same preventative steps as we have with VS Online and Codeplex.  If you are on some TFS 2013 Update other than 4 (Update 1, 2 or 3), you will need to upgrade to Update 4 before applying the patch.
1. TFS 2013 RTM patch
2. TFS 2013 Update 4 patch
3. We have released patches for Visual Studio 2013 RTM, Visual Studio 2013 Update 4 and for our VS 2012 VSIX extension so customers can patch their clients to be safe.  Note, Visual Studio does not use any of the Git aliases but we want to be sure that VS cannot be used as an attack vector to get a malicious config file downloaded on to people’s machines such that the attack completes the first time the developer drops to the command line to use some git CLI.  If you are on some VS 2013 Update other than 4 (Update 1, 2 or 3), you will need to upgrade to Update 4 before applying the patch.
1. VS 2013 RTM patch
2. VS 2013 Update 4 patch
3. VS 2012 VSIX update
4. As part of all of this, we also worked together with the community to patch the LibGit2 open source library that many of us share as the core of our Git implementations.

You’ll find other important, related posts here:

• Main announce post: http://git-blame.blogspot.com/2014/12/git-1856-195-205-214-and-221-and.html
• Core git patch:   https://git.kernel.org/cgit/git/git.git/commit/?id=3f1509809e728b70ea7912e4e1b40f22965e45ee
• Git for Windows: http://msysgit.github.io/

Hopefully this clearly explains the issue and what you can do about it.

Brian

Brian Harry Corporate Vice President, Cloud Developer Services

Follow