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.
- 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.
- 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.
- 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.
- 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
Sorry. I just fixed the paste error that I had in the initial post.
Brian
Hi Brian, do you know if there is plan to release a fix for VS2015 Preview? (sorry if this is a double post).
@Dave Shaw, We certainly will provide a fix for our VS 2015 previews. Because they are previews, we're not set up to service them. We will be releasing a CTP in mid-Jan with a fix. The advice I have for you until then is don't use the VS 2015 preview to pull/fetch/sync from a repo that you don't really trust. Use a patched command-line or something for pulls if you are not completely certain.
Brian
@Cheers Brian – I'm pretty much using VS2015 full time at home the moment, I'll keep my cloning and pull's to command line for now.
Note that this is not limited to .git/config but .git/$anything (including .git/hooks/$something).
Will the VS2013 Community Edition be updated? Or will it be patch-able with the "VS 2013 Update 4 patch"?
@Pandu – the VS2013 Update 4 patch will update all editions of VS2013 including Express, Community, Premium and Ultimate editions.
jeff
"Using an alias, pretty much any git command can be repurposed to do anything you want."
Are you sure about that? Some time ago, I tried to create an alias named "stage", and it didn't work because "stage" is a built-in Git command (it's a synonym for "add")
Anyway, there are other ways to exploit this vulnerability, e.g. by installing a malicious hook…
This patch only applies to the app tiers, correct?
@Jay B, For TFS, yes. Of course, you need to update Git command lines and VS anywhere you have installed them.
Brian
@Brian, I've been using 2014ctp3, on win10, VS2015 say no support of 10, the virtual desktops on 10 are really helpful do Dev, I can see moving from win7 to this ASAP, I would be willing to pay$ for a stable win VS version(still stuck on 2010).
I tried vs2015 on Win7 in an attempt to test .Net 4.6, I've been doing a lot of win10 installs, takes 10 min on atom,
vs2015 takes hour on fast clean i7 form ISO, ignores install option and installs kitchen sink, black UI, ok, its preview,
but windows says it 4.5.3 , 4.6 download page show same thing, looks rush and really sloppy packaging, ok it's preview, then almost an hour to uninstall?, from fast raid 0 ssd array, NOT OK, shameful, is the VS team proud of that packaging, how fast can you install and uninstall?,
I need a stable Win10 environment,which it looks like I have right now, but I'm worried about when 2014ctp3 expires, ctp4 coming?, I cant find anything on the 4.5.3,4.6 thing, am I the only one testing this stuff?,
I feel bad complaining in light of the Win10 and WPF, I think I now the answer to this but please tell me that at some point the VS team is gonna stop fiddling with UI and other non-IDE related issues and release at least one stable non-scrum based version for Win10.
Will the patches be pushed as security updates through Windows Update?
Related to Jared S' question… Will this be pushed out to VS clients via the push notifications in Visual Studio? I'm looking this morning and I don't see it available in the Extensions and Updates dialog.
Running VS 2013.4.
Thanks,
Matt
رازی
Is it possible to report on, via SCCM or otherwise, who has the 2012 VSIX extension so that the Git patch can be deployed only to those machines? Does it register itself in Add/Remove or as a "Product"? I understand that the VS SDK is needed before that extension can be used. What would happen if the Git patch would be attempted to install to computers without VSIX?
I'm speaking only to 2012 here since I understand that all unpatched VS 2013 instances are vulnerable, but not all with 2012.
@Matt, We're looking at delivering a notification through the VS Notifications hub. Hopefully in the next week or two. We are not planning on doing a Microsoft Update push.
Brian
@Dan B – The VS Tools for Git VSIX cannot be installed without having VS 2012 Update 2 (3, or 4) installed. The installer will block in all other cases (including having a newer VS version installed, e.g. VS 2013). I don't have a machine with VS2012 installed at the moment, so I can't confirm if the VS Tools for Git will show an Add/Remove Programs entry. We'll have someone follow up to confirm.
@Dave.
The .NET version string issue is a known issue that wasn't completed for the preview. The following was included in the docs:
".NET Framework 4.6 Preview will display as framework version 4.5.3 in some places in Visual Studio 2015 Preview such as the Target framework list of the Application Properties page."
Installation will be very different in the release candidate and should allow you more control over what is installed.
When you say "2014ctp3 expires", do you mean VS 2015?
Brian
@Brian, yes VS2014ctp3
http://www.visualstudio.com/…/visual-studio-2015-compatibility-vs.aspx
say n/a for Windows 10, so I haven't tried yet, FWIW 2014ctp3 and 4.6(4.5.3) runs on 1Gb ram,7 inch tablet, slow, but stable Win10 build 9944, the virtual desktops in Windows are perfect for Dev workflow, so even rough ETA on stable VS2015/Win10 compatible would be great. thanks
I'd expect we'll have a reasonably stable/complete VS 2015 preview in Q1 of this year.
Brian
@Dan B – just following up, the Git Tools for Visual Studio extension does show up in the Add/Remove Programs list when it is installed.
That's great, thanks Matthew.
If we are on TFS 2013.RTM, we install this Git patch, and then we upgrade to TFS 2013.4, so we need to reinstall the Git patch?
@Aaron, yes.
Brian