2

The recent remote code execution bug in git looks pretty serious. The way I read this is that if I'm running a git client prior to 2.7.1, I'm susceptible to remote code execution if I use git to interact with a malicious (or compromised) repo. It seems like a manual upgrade of the git client is in order, but rootless prevents things like brew from working. (I'm currently on the latest stable Xcode 7.2.1)

What's the best way forward under El Capitan? Turn off rootless and install with brew? Install an updated git client from source? (latest stable binary appears to be prior to 2.7.1) Is there an updated git client in a newer version of Xcode?

4
  • Could you edit this to narrow down what you seek to do? Remove the git client binary? Put a new one in your path? What is your setup. Are you serving git repos? Using Xcode? Or are you just looking for someone to say that out of box ElCapitan don't listen to git and aren't hackable?
    – bmike
    Mar 17, 2016 at 14:24
  • Updated. Current stable git client (in xcode and stable binary from git-scm) appears to be prior to 2.7.1 and has a remote code execution vulnerability. Seeking guidance about the best way to manually update the git client to a non vulnerable version under El Capitan.
    – jorfus
    Mar 17, 2016 at 17:39
  • Thanks for the edit. Wikipedia's definition of RCE is triggering code execution remotely - so using git client to pull code from a malicious repository seems lower than RCE in my book. Nevertheless - assuming you just want to know how to avoid using a vulnerable git client until/if Apple patches it, let's open this for now and see what comes up.
    – bmike
    Mar 17, 2016 at 18:11
  • 1
    Homebrew works fine with system integrity protection. See @CD-RUM 's answer and my comment for more details. If you're having trouble, you probably have an old b0rked Homebrew installation that didn't survive the upgrade well (this is particularly likely if you went through the beta programme). In that case, Google for ways to fix your Homebrew as it's probably the cleanest way to maintain this kind of software and manage updates. Mar 21, 2016 at 19:48

3 Answers 3

3

If you use Homebrew it's pretty easy:

brew upgrade git
which git
=> /usr/local/bin/git
git --version
=> git version 2.7.3

Done.

1
  • 1
    I don't know why this isn't getting more votes. Homebrew was updated a long time ago now and works fine with Rootless in El Capitan; /usr/local and /Library/Caches/Homebrew are not protected filesystem locations: support.apple.com/en-us/HT204899 ("Paths and applications that third-party apps and installers can write to include: /Applications, /Library, /usr/local"). Mar 21, 2016 at 19:46
2

Brew doesn't ever work to replace or patch an OS version - it's consciously designed to only put binaries beside those from Apple and not in place of.

If you want to make sure that no program calls Apple's /usr/bin/git or you don't call it, then these steps will accomplish that goal of hardening your 10.11 installs:

  1. Run OS X Recovery by holding down Command-R while the Mac is starting up.
  2. Use the Utilities menu to run Terminal
  3. csrutil disable
  4. reboot
  5. Enter single user mode by holding Command-S while the Mac is restarting.
  6. mount -uw /
  7. rm /usr/bin/git
  8. halt
  9. Repeat the OS X Recovery step and open Terminal and run csrutil enable
  10. reboot

At this point, the git from Apple is removed.

Search for other git binaries:

  • /Library/Developer/CommandLineTools/usr/bin/git is 2.5.4
  • /Applications/Xcode.app/Contents/Developer/usr/bin/git is 2.5.4

You are at very slight risk since you only ran without SIP in single user mode long enough to remove the one binary. You can also get git 2.7.4 from brew as of March 18, 2016 if you like:

brew install git
git --version

You'll want to watch all OS X updates to be sure they don't pop another copy of git that's patched lower than you wish. For most people, I would focus on only connecting to servers that are patched and/or known to be not malicious. Just having the git sitting there is low risk in my read of the situation.

Some other threads of interest:

5
  • Does Xcode search in /usr/local/bin at all?
    – nohillside
    Mar 17, 2016 at 18:49
  • I can test that @patrix in a bit. My recollection is that it packages it's own git, so perhaps someone that wants to eviscerate all old git binaries needs to search more thoroughly than just in /usr/bin. Specifically the current command line tools have /Library/Developer/CommandLineTools/usr/bin/gitat 2.5.4
    – bmike
    Mar 17, 2016 at 18:52
  • So to protect a developer system these git binaries need to be replaced as well I assume (there is /Applications/Xcode.app/Contents/Developer/usr/bin/git and /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core/git in Xcode, also tools like Github.app or SourceTree.app include their own git). So protecting a system will require more than just disabling /usr/bin/git.
    – nohillside
    Mar 17, 2016 at 19:05
  • 1
    I've found ls -dl $(locate 'git' | grep '/git$') useful to find the various git's in the system.
    – nohillside
    Mar 17, 2016 at 19:06
  • Yup @patrix - it's a bit of a zoo with git being embedded in lots of places. I could easily see people with half a dozen versions between brew, Apple and a couple of utilities to visualize git repos.
    – bmike
    Mar 17, 2016 at 19:30
0

I don't have any workflow wherein other tools are calling git so I'm ok with simply installing a patched version and using that.

I did the following:

  • Cloned from the official git repo
  • Installed with make && make install
  • And prepended ~/bin to my path in .profile

That should work fine for me I think.

As for only interacting with trusted sources --sure, that's ideal, but there's no excuse to use a known vulnerable piece of software. There are plenty of examples of trusted sources getting compromised. Having a git clone actually able to execute arbitrary code is undesirable in my view.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .