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.

chmod -x? Not so fast.

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.


Original URL: http://feedproxy.google.com/~r/feedsapi/BwPx/~3/ul-6FySFdoI/

Original article

Comments are closed.

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑

%d bloggers like this: