Rogue Source Code Repos Can Compromise Mac Security Due To Old Git Version (softpedia.com)

An anonymous reader writes: Recent Mac versions come bundled with a very old version of Git (2.6.4) that is vulnerable to two security flaws that allow attackers to execute code on the device when the user forks a Git repo holding "malicious" code. The problem is that users can't upgrade this Git repo, they can't change its runtime permissions, nor can they remove it because Apple blocks even root users from twiddling with some system-level programs. "If you rely on machines like this, I am truly sorry. I feel for you," the researcher wrote on her blog. "I wrote this post in an attempt to goad them [Apple] 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."

Comments

Compile and path

[Moblaster]

Well why can't you just compile a new git and stick it in your path?

Re:Compile and path

[Anonymous Coward]

Because OS X resets PATH to the system defaults stored in /etc (which you can't edit for the same reason you can't update git) on anything launched by launchctl, which is basically anything you don't launch directly via the shell.

Re:Compile and path

[Anonymous Coward]

~/.profile won't work, because launchctl ignores it.

In OS X, programs that are launched from the GUI have never touched an actual shell. Their parent process is "launchd" and "launchd" is init. As I understand it, as of OS X 10.9, launchd simply hardcodes the PATH and entirely ignores the contents of /etc. Prior to that it would use /etc/environment or something like that (but not /etc/profile).

When you launch something from the Dock or double-clicking on it, it's launched via launchctl and that ultimately execs it off launchd. It never sees a shell and never sees ~/.profile.

So you can replace git and use a different git in shells you start, but if you want to prevent, say, an IDE from using the system git it finds via the PATH - you can't. There's no way to adjust the PATH that the majority of applications use.

Re:Compile and path

[Anonymous Coward]

You can also update the system path with the following and reboot.

sudo launchctl config system path 'xxx'

Re:Compile and path

[Darinbob]

You can fix this stuff. True, the latest El Capitan crap tries to prevent root from doing some things but you can override it with the secret mantra easily found in web searches. Anyone using "git" on OSX is probably already using Mac Ports or something similar. The default tools that come with OSX or Xcode really only exist as an iOS development support system and can be ignored.

Re:Compile and path

[cbhacking]

In what way are AppArmor or SELinux in any way like launchd or systemd? Also, while you may be super 1337 and sandbox all your applications using chroot jails and who-knows-what-else, AA and SEL provide a hell of a lot more security than what people normally do, which is just run programs as whatever user you happen to be logged in as.

Re:Compile and path

[lucm]

You are technically correct but SElinux is a real pain in the ass.

This reminds me of the hilarious definition of Level 2 in the CIS benchmark for RHEL:

Level 2: may negatively inhibit the utility or performance of the technology

https://benchmarks.cisecurity....

There comes a point where hackers cause less damage than this kind of "security".

Re: Compile and path

[jeremyp]

Changing the path with launchctl is not one of them.

Re:Compile and path

[jeremyp]

The default tools that come with OSX or Xcode really only exist as an iOS development support system and can be ignored.

Yes, and I do. However, if you use the git integration of Xcode itself, it is hard coded to use the built in to Xcode version of git i.e. the vulnerable one.

Of course, nobody in their right mind uses the Xcode source control because it is rubbish.

It's Impossible!!!

[konohitowa]

sudo port install git
echo "export PATH=/opt/local/bin:\$PATH" >> ~/.bashrc

Oh! The humanity!

(Requires https://www.macports.org/insta...)

As an aside, it's possible to override SIP, but it's a bit of a PITA.

Re:It's Impossible!!!

[93 Escort Wagon]

Yup, boy howdy that was hard.

$ git --version
git version 2.6.4 (Apple Git-63)
$ fink install git
... chatty installation text ...
$ hash -r
$ which git
/sw/bin/git
$ git --version
git version 2.8.0
$

  But, still, it is annoying that a lot of the various standard developer tools provided by Apple are significantly older than their current counterparts on most other Unix systems.

Re:It's Impossible!!!

[mwvdlee]

What changes between 2.6.4 and 2.7.2 do you think are so important that they warrant the risk of potentially breaking Xcode's SCM system that sits above it?

Apparently not security fixes; those aren't important enough for Apple.

Yes, you *can* replace /usr/bin/git

[Guy Harris]

First, you turn off System Integrity Protection by following the directions on Apple's Configuring System Integrity Protection page.

Then, you replace it (or any other program you want, including /System/Library/Kernels/kernel).

Then, if you want, you turn System Integrity Protection back on.

Re:Yes, you *can* replace /usr/bin/git

[Guy Harris]

I'll get my grandmother on that.

If your grandmother uses Git from the command line on her Mac, and would otherwise be capable of replacing /usr/bin/git, she might not find the extra steps described in Apple's document too problematic.

Re:Yes, you *can* replace /usr/bin/git

[Space cowboy]

If your grandmother is checking out code from a git repository (and much kudos to her if so) then she won't have a problem disabling SIP...

Re:Yes, you *can* replace /usr/bin/git

[timritzer]

Lol, your grandmother is regularly forking unknown source repos? Because if so, she can handle fixing it....

Re:Yes, you *can* replace /usr/bin/git

[Anonymous Coward]

You should. She apparently already installed Xcode and is forking various git repos.

Re: Yes, you *can* replace /usr/bin/git

[Guy Harris]

Apple thinks the users of their products are too stupid to handle root account.

If you mean "Apple makes it hard to log in as root", true, but so what? About the only OS into which I log in as root these days is Solaris 10, and that's because they don't let you do a clean shutdown of the system as an ordinary user (unless I've missed something) - I use sudo or su in those cases where I need to do stuff as root.

What makes Apple think their users understand SIP?

Most of their users neither understand it nor need to understand it.

Some of their users do need to understand it, and can understand it; that article is published for them.

Re:Yes, you *can* replace /usr/bin/git

[Guy Harris]

The exploit is about a GUI program that invokes git, not using git from the command line.

The exploit is about the git program. The only difference between the GUI program running it and running it directly from the command line is that you can set $PATH so that the command git would run a newer version from /usr/local/bin or ~/bin or wherever, whereas that's more difficult or even impossible to do so from, for example, Xcode.

And, in any case, if your grandmother uses Git from Xcode, and would otherwise be capable of replacing /usr/bin/git, she might not find the extra steps described in Apple's document too problematic, so the "I'll get my grandmother on that." comment was extremely idiotic.

Re: Yes, you *can* replace /usr/bin/git

[Space cowboy]

Away bollocks. You're just trying to score cheap points.

There is no way my mother (not speaking for OP's grandmother here) will ever open Terminal.app, let alone type in 'git clone xxxxx'. She doesn't know what 'download.com' *is*. For people like my mother, Apple computers are indeed better.

For tech-savvy developers (i.e. People who know what './configure' is, or 'make', following the step-by-step instructions for disabling SIP is trivial. Or, you know, they can just install macports (standard install package from a dmg), change their path to put /opt/local/bin first and then type 'sudo port install git'. Problem solved.or they can use fink, or they can use brew, or, since they're so up on git and they could just clone the git repository, build and install it themselves.

SIP is a good thing, even though it's a pain in my arse as a kernel extension developer. Sure, if a vulnerability shows up, there are more steps to fix it, but it will almost certainly be fixed in the next s/w update now, there are ways around the problem, and in general SIP stops malicious apps from replacing system binaries even when they have compromised the root account.

But hey, let's bash Apple huh ? Having actually read the post on the authors site, it reads like a six-year-old wrote it. It's full of biased opinion and even starts off with a chicken-little "oh the world is ending" allegory about those poor innocent small-business developers.

I wonder if the author went the responsible route of filing a radar with Apple and seeing what they'd do about it before announcing that the end of the world is nigh, or whether she just tried to score cheap internet points to bolster her own biased viewpoint about Apple products in general. Really, I wonder /s

Simple fix to old rogue source code issue

[helixcode123]

sudo port install nethack

Re:Simple fix to old rogue source code issue

[Anonymous Coward]

You made my day. Here, have a dog.

d

Not Apple's Fault

[Anonymous Coward]

It's not Apple's fault here. The git community developers completely and utterly botched this vulnerability. They announced it to the world, claiming it was fixed in 2.7.1 only to retract that a few days later after releasing 2.7.3 and then finally fixing it in 2.7.4. Apple released Xcode 7.3 just a couple days after git-2.7.4 was released, so it's no surprise that it doesn't contain the fix.

Had the git community actually disclosed companies ahead of the announcement (and better yet, had released a fix before the announcement, or even have been *accurate* in the announcent), the vulnerability likely would have been fixed in Xcode 7.3. As it is, developers need to wait for Apple to spin an updated version of Xcode for this fix.

The blame lies 100% on the git community for this debacle.

See https://marc.ttias.be/oss-security/2016-03/msg00195.php for more details about how they completely failed here.

Re:Not Apple's Fault

[shawn2772]

The blame lies 100% on the git community for this debacle.

That was true for a few days after the release of 2.7.4, maybe even a few weeks, if we're generous. But the blame gradually shifts to Apple as time goes on and they leave the vulnerability unpatched. By now, it's 100% on Apple. It's not as though Apple doesn't have a mechanism for delivering patches, either.

/usr/bin/git *ISN'T* git

[Anonymous Coward]

Why is everyone so focused on replacing /usr/bin/git on their Mac? It's not git. It's just a stub that uses libxcselect to find git within Xcode:

$ otool -L /usr/bin/git /usr/bin/git: /usr/lib/libxcselect.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)

If you really want to replace it, replace the one inside of Xcode:

$ xcrun -f git /Applications/Xcode.app/Contents/Developer/usr/bin/git

Or just wait for Apple to release an update with the fix, and go yell at the git developers for completely screwing up the disclosure of this vulnerability, thereby not giving companies time to prepare a release with the fix.

Re:/usr/bin/git *ISN'T* git

[jeremyhu]

Uh, git is open source software. The git developers released their fix.

On March 17. The final Xcode 7.3 seed had already been delivered to developers and was released in the app store two days later.

Are you really suggesting that, since some 3rd parties (Apple in this instance) decided to bundle git with some of their stuff, that git developers can no longer release their software until they've coordinated with every single 3rd party out there?

No, of course not. I'm saying that they should follow good security disclosure practices and coordinate with vendors like other open source projects do. If they're aware of a vulnerability, they should disclose it to vendors (Ubuntu, Fedora, RedHat, FreeBSD, OpenBSD, NetBSD, Oracle, Microsoft, Apple, ...) like other OSS projects do. X11 does this. Other OSS projects do this. Git does not.

The git developers announced this to the world before even they had released a version with the fix even though the fix had been available on master for a few weeks prior. There was no coordination with vendors (or even with themselves).

Once git software is released, the bug is essentially disclosed because the source code for the patch is available.

It's not like Apple were caught off guard either. The version of git they're distributing is several major revisions out of date.

That's not at all true. Apple was definitely caught off guard, as was the rest of the industry. The issue was disclosed 2 days before the fix was released. It was reported to be fixed in a version of git that actually didn't even have the fix.

The version of git that is included on Xcode 7.3 was the latest stable version available when Xcode 7.3 went to beta. git 2.7.0 was released just days before Xcode 7.3.0 beta 1 was seeded to developers, and taking a new major version .0 of git at that time would not be appropriate (given that stability and reliability is a primary concern). The point is to deliver a mature, stable version of git to developers that works well and is well tested with Xcode's IDE SCM and Xcode Server. Users that want the bleeding edge version of git (which updates major versions about every other month) should install it themselves because it's simply not possible to include the latest version at Xcode GM and guarantee a well tested and stable experience to Xcode users.

Re:/usr/bin/git *ISN'T* git

[jeremyhu]

One difference between Apple's products and Linux distributions is that with distros, you actually get an update to git. With Xcode, you need to get an update to Xcode which contains git. git is used by Xcode for a variety of things and needs to be tested and verified to work correctly with the updated version of git underneath it. It would be bad to fix the vulnerability only to break Xcode's SCM system because of a regression in git.

Quality is a primary concern, and it takes time to test and qualify changes. Many other OSS projects recognize this and have a mailing list to discuss vulnerabilities between developers and vendors ahead of the fix landing and CVE publication. This allows vendors to prepare the fix for their pending releases instead of getting caught off guard by an announcement made at inopportune times that leaves them with no option for shipping a fix and hurting their customers.

Re:She's Assuming Naive Devs, Then

[fnj]

Granted, it's a bummer that Apple hasn't tended to the Git client shipped with Xcode.

Also, just as one more example, even as of OSX 10.10 Yosemite, the shipped version of bash is prehistoric.

Re:Forking is for GitHub

[bondsbw]

In a distributed VCS like git, there isn't really a distinction between clone and fork.

The operation is the same but the purpose is different... a fork provides the ability to push changes to the hosting service when you don't have write access to the original repository. A local clone is usually distinguished from a fork in this way.

Re:Very old?

[jeremyhu]

Apple's record on security updates is pathetic and their lack of communication doesn't help matters. Unless they are prodded by the press, their standard position is to remain silent.

What makes you say that? Vulnerabilities fixed in Apple updates are well documented:

https://support.apple.com/en-us/HT201222

Re:She's Assuming Naive Devs, Then

[TheRaven64]

The version of bash shipped is the last GPLv2 version (plus patches). Apple doesn't ship any GPLv3 code.

Re:Simple Fix

[Ash-Fox]

Xcode isn't using it despite the path being set when launching xcode.

Re:Very Old?

[Lumpy]

It's an apple hate story that actually is devoid of anything useful.

Re: Sunds pretty fishy

[macwhiz]

What, you mean the USB HID standard that defines two axes of movement (X and Y) and three buttons? Or the Microsoft convention that certain buttons, on certain mice, should be mapped to forward and back—there being no actual standard for which USB HID button numbers should be mapped to those functions?

Solaris RBAC / Shutdown

[Tenebrousedge]

Depending on what you mean by "clean shutdown", you should just have to do some RBAC setup:

Edit /etc/security/exec_attr and add the following profile:
exec_attr:Shutdown:suser:cmd:::/usr/sbin/shutdown:uid=0;gid=1

Add this profile to /etc/user_attr
yourusername :::: profiles=Shutdown

Then your user can shutdown with /usr/bin/pfexec /usr/sbin/shutdown

Instructions taken from here.

As to the more general topic, all major OSes operate on the "Principle of Least Privilege", which in this case means discouraging casual use of the superuser account, or disabling it entirely. With apologies to Twain, "Suppose you were logged in as root all the time, and suppose you were an idiot. But, I repeat myself."