Exploiting CVE-2014-9390

On the face of it,  CVE-2014-9390 seems like quite a nasty vulnerability. It gives an attacker the ability to modify a local git repo's .git directory (where all your config and other fun things, including scripts) are stored. This directory should be protected from modifications via the contents of a remote repo, owing to checks performed by git when performing the copy.

The git client should ignore .git directories on the remote server, however its been discovered that although .git will be ignored, .gIT, .GIT, .git~123 etc will happily be pulled to the local file system. Now, if that filesystem is case sensitive, no issue: the local .git will remain intact, and the new folder will snuggle up alongside it. However... in case insensitive filesystems (Mac HFS+ and Windows NTFS) the example .gIT is for all intents identical to .git, and hopefully you can see where the problem lies.

How easy is this to exploit? Lets find out...

After quickly setting up a git server and evil repo, we can can create some evil content for that repo. In this case, I'm using a post-checkout script, which does pretty much what it says on the tin: executes  on the client every time a branch is checked out. The script calls the oh-so-evil executable notepad.exe, but this could easily be something far more worse:

Add the evilness and commit to the remote repo:

Attempt a clone to a local Windows repo:

And BOOM! There is notepad.exe, called in from the post-checkout script hosted in our evil repo. Git failed to identify that our evil .gIT was something it shouldn't be cloning, Windows NTFS ignored the case of the pulled-in evil directory, and our evil post-checkout script was merged into the local .git/hooks directory (which got created with default values the instant we ran the clone command)

Git client used for this test was version 1.8.3 

So, is this bad? Yes... oh yes... Should you update your local git clients? Yes. 

Go on, go update now.