Remote code execution, git, and OS X

Remote code execution, git, and OS X

Sometimes I think about all of those pictures which show a bunch of people in startups. They have their office space, which might be big, or it might be small, but they tend to have Macs. Lots of Macs. A lot of them also use git to do stuff, perhaps via GitHub, or via some other place entirely. There are lots of one-off repos all over the place.

So you have lots of people running Macs and running git. Great, right? Peace, love, and free software?

It's not all good. Let's say you're running El Capitan. What git do you get with your system? I installed it tonight just to find out:

mini$ git --version
git version 2.6.4 (Apple Git-63)

git 2.6.4. Is anything wrong with that? Well, yeah, actually. Say hello to CVE-2016-2324 and CVE-2016-2315, present in everything before 2.7.1 according to the report. You should check this out.

Remote. Code. Execution.

My reading suggests that if you were to point a vulnerable version at a repository which is controlled by an attacker, then they could run code as you on your machine. Once that's done, it's game over. They own you.

So, what's the big deal? Crappy C code gets exploited every day, and we upgrade it, and then we're "safe" until the next huge hole that's been there forever is reported. (In the meantime, people party with their private stash of vulnerabilities.)

But what if you couldn't upgrade it? Remember when I said El Capitan? Apple is doing something new which basically keeps you from twiddling certain system-level programs without going to fantastic lengths. Not even root is enough to do it. In short, you can't just replace /usr/bin/git.

Maybe you want to be clever and protect your users by disabling it until you can figure something else out. Well, sorry. You also can't "chmod -x" to at least keep it from being used. It will also fail.

You might know a thing or two about how Apple provides these programs, and the fact that git and 64 other files in /usr/bin are all the same size (18176 bytes on my machine) might clue you in. You might think "aha, it's some kind of abstraction", and you're probably right. But, where's the "real git" then?

I know, I'll just strace it to see what it execs! Oh wait, this isn't Linux. Uh, I'll dtruss it to see what it execs!

$ sudo dtruss git
dtrace: failed to execute git: dtrace cannot control executables signed with restricted entitlements

Or not. Try to strings it, same deal. You actually get no output on the OS X machine. It takes GNU strings on a Linux box to get results, and none of them point you in the right direction.

I'll save you the trouble of digging through your entire machine and tell you that you will probably find it in /Applications/Xcode.app/Contents/Developer/usr/bin. If you chmod -x that binary, then 'git --version' will eventually fail to run, as you originally wanted. Now you can be sure you won't accidentally run it while you figure out an upgrade strategy.

Of course, upgrading over top of that will almost certainly screw something up later. It's times like this when you depend on the vendor. Well, vendor, how about it?

Oh, and, incidentally:

$ xcodebuild -version
Xcode 7.3
Build version 7D175

If you rely on machines like this, I am truly sorry. I feel for you. I wrote this post in an attempt to goad them into action because this is affecting lots of people who are important to me. They are basically screwed until Apple deigns to deliver a patched git unto them.

Let's see what happens.