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.

Re:Compile and path

[Anonymous Coward]

It would figure that looking up how to do that via a Stack Overflow question got the answer "it can't be done" but saying "it can't be done" on Slashdot got me the right answer.

Re:Compile and path

[Guy Harris]

Hmmm, "launchd" is awfully close to the spelling of "systemd", should I be concerned and/or outraged?

Well, you definitely should not be surprised.

(I.e., Lennart likes the idea of launchd.)

Re: Compile and path

[Keybounce]

As part of anti-malware prevention, Mac OS X protects a number of critical files from being modified, even by root.

There are two work-arounds:

1. Install a second copy of the OS (repartition the drive to include a second partition).
2. Use the recovery boot

In both of these cases, the system files relative to "/" are still protected, but the files in /Volumes/RealRoot/usr/bin/whatever are now not protected.

** NB: The list of protected files is itself contained in a file! **

Said file is protected, but you *can* boot in the recovery boot, empty that file (or other specify that the entire disk is not protected), and then you have full control (And exposed risk) as root.

So you can disable or work-around this feature.

Re:Compile and path

[Plumpaquatsch]

Hmmm, "launchd" is awfully close to the spelling of "systemd", should I be concerned and/or outraged?

Depends on what you want to achieve. If it helps your decision, launchd is 10 years old, systemd only 5.

macports

[feranick]

sudo port install git
Not that complicated.

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

[konohitowa]

Oh, how droll. You assume /.-ers are imbeciles incapable of handling the command line.

Re:It's Impossible!!!

[konohitowa]

As I expected, spending 5 minutes typing a simple example to make a point brought the insecure people out of the woodwork.

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.

Re:It's Impossible!!!

[jeremyp]

You don't need the second line. MacPorts automatically adds the correct path to your profile to make it override the built in tools.

Re:It's Impossible!!!

[Khyber]

Most current /.ers certainly can't handle the command line. They were born in the age of the GUI.

How thoughtless of you.

Re:It's Impossible!!!

[jeremyhu]

There were no security issues addressed between 2.6.4 and 2.7.2. The vulnerability was fixed in 2.7.4, but I understand your confusion because upstream incorrectly advertised the issue as fixed in 2.7.1 on March 15 before actually fixing it in 2.7.4 on March 17.

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

[kuzb]

...just as soon as you finish training her to use version control.

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

[lucm]

Two points.

1) forking github repos has long stopped being something that requires deep technical skills, it's basically the modern Download.com

2) Apple products are supposed to be designed for regular people and Apple ecosystem is supposed to be closed so they can control quality. Fail and fail.

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

[Guy Harris]

How dare you fight against Apple's supreme power and use your machine to do that?

Because Apple helpfully told me how to do it.

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

[Guy Harris]

What a shitty SIP.

Microsoft Windows has this. If you turn it off, modify files that are not signed properly, then turn it back on... it complains system files have changed.

You have to specifically make an exclusion or use only properly signed files.

Are you referring to Windows File Protection, Windows Resource Protection (which apparently replaces Windows File Protection in Vista and later), or some other mechanism?

So presumably there's some way to turn off protection of a particular file without turning the protection off entirely; otherwise, this is just like System Integrity Protection, with "turn off protection of a particular file" being done by turning its "restricted" flag:

$ ls -lO /bin/cat
-rwxr-xr-x 1 root wheel restricted,compressed 23520 Jan 13 18:13 /bin/cat

with

sudo chflags norestricted

on the file, which you could do on OS X only when System Integrity Protection turned off.

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

[Aaden42]

1) forking github repos has long stopped being something that requires deep technical skills, it’s basically the modern Download.com

What universe are you living in? I’m pretty confident saying that zero of the humans I know who don’t work directly in programming-related IT fields don’t even know what ‘git’ is. The British non-coder folks I know might think I’ve just insulted them, but other than that, blank faces all around.

That kind of thinking from a rarified environment is why simple things that “we all know” we shouldn’t do turn into huge security issues. We all know, but they don’t. They outnumber we by a huge margin. And FSM willing, they always will. That’s called “job security.” You can’t create interfaces built on the assumption that users have the same background knowledge that we’ve acquired through years or decades of daily immersion. When security fails in those situations, it’s the programmer, not the user who did something stupid.

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

[Aaden42]

If you *modify* a signed file, thus invalidating the signature, neither Windows nor OS X will run it, SIP or not. When you turn off SIP, replace a signed file with an unsigned one OR a file validly signed with another key, then you can turn SIP back on, and the file you modified stays as you left it.

To my knowledge, there is no way to get OS X to run an invalid signed file (IE signed, but modified since it was signed). There’s not even an override for that (nor should there be, IMHO). OS X tells you the file is damaged and moves it to the trash. You could strip the signature and run it that way if you wanted, but as long as there’s an invalid signature attached, it won’t execute, regardless of SIP settings.

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

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

[MrKrillls]

"For people like my mother, Apple computers are indeed better."

Maybe. Maybe not.

Someone is going to have to support Mom's computer. If it's a Mac, that person will have to be one level more savvy to get around Apple's user protective stuff. i.e. I won't be able to keep Mom's machine working because all the extra junk is one step beyond my knowledge. I'm not a developer - just a user who has figured out that the non-proprietary OSs are the sweet spot for user maintenance. Add proprietary and easy maintenance goes south.

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

[Space cowboy]

My mother has a Mac. She's 6000 miles away. Number of support calls needed over the past several years ? 0.

I installed it at Xmas one year when I was over there, and since then have had zero trouble with it. Now my brother has to maintain my father's PC now and then (example: he clicked the UPS email when UPS were indeed delivering that day), but *fortunately* he's only a couple of hundred miles away /s

I stand by the statement. For people like my mother, Apple computers are indeed better.

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

[Guy Harris]

There are programs other than XCode that might use git as well.

Yes, but that's irrelevant to the point, which is the the original crack about the grandmother demonstrates nothing other than that Rockoon hadn't bothered to engage their neocortex when making the crack - yes, there are other GUI programs that might use Git, but if your grandmother is using one of them, and is capable of replacing /usr/bin/git, it's very likely that your grandmother has enough technical chops to turn off System Integrity Protection.

You're a cheerleader,

No, I'm somebody who doesn't like bogosity (such as "Apple completely prevents you from replacing /usr/bin/git") being propagated.

so I understand your intense need to defend Apple,

I'll defend anything, from anybody, from what I think to be technically incorrect and false criticism. Perhaps the problem is that the current favorite target of ill-informed foeboys happens to be Apple, so there's currently more ill-informed criticism of Apple than of, say, Microsoft or the Linux community, but I've blasted ill-informed criticism of Windows and Linux in the past as well.

And I'm perfectly willing, for example, to rip Apple's protection of programs in /usr/bin that merely run other unprotected programs in /Applications/Xcode.app/Contents/Developer/usr/bin or elsewhere for being a royal pain, breaking, for example, attempts to run /usr/bin/lldb from libtool to debug a built-with-libtool binary in its build directory. (Yes, I filed a Radar. Yes, they blew it off.)

but try to think a little every once in a while.

I do so all the time. You might want to try it yourself, for a change.

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

[lucm]

But hey, let's bash Apple huh ?

There has been no Apple bashing in this thread. Not getting on one's knees to worship Apple is not the same as bashing Apple.

You remind me of those people who say they've been cyber-bullied because nobody "Liked" a comment they posted.

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

[Space cowboy]

From the post above mine, which I was replying to:

"Apple products are supposed to be designed for regular people and Apple ecosystem is supposed to be closed so they can control quality. Fail and fail."

"Fail and fail" is generally considered to be uncomplimentary. Just FYI.

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

[lucm]

"Fail and fail" is generally considered to be uncomplimentary. Just FYI.

And you consider that bashing? Have you been raised by hippies?

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

[Space cowboy]

I'm not sure what hippies are, so I doubt it, but I do understand what politeness and manners (and their opposites) are.

Forking is for GitHub

[Anonymous Coward]

When you make a copy of a git repository on your machine, it's called "cloning" the repo. "Fork" is a GitHub buzzword.

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.

Very old?

[Anonymous Coward]

I'm annoyed this is a problem and would like Apple to fix it, but using bullshit to spread a story is a bit counter-productive.

It's not old (about 4 months since release, mid-Dec 2015) and unless you're using integrated git in Xcode, very easy to upgrade via brew or macports.

Re:Very old?

[jeremyhu]

Yes, there have been updates to OS X since December, but that's not at all relevant here for two reasons:
    1) OS X does not ship git
    2) The vulnerability wasn't fixed until late March (just a few weeks ago)

git 2.6.4 was shipped mid December, and Xcode 7.3 went to beta in early January (shortly after git 2.7.0 was released). Given that there were no security fixes in 2.7.0, 2.7.1, 2.7.2, and 2.7.3 and taking a newer version of git increases risk to Xcode due to changes in git, it's logical to expect that the version would not be updated to any of those versions after entering beta.

The git vulnerability was announced on March 15.
A fix was made available in git 2.7.4 on March 17.
Xcode 7.3 was released two business days later.

Obviously two days is not enough time for Apple to update Xcode's git to a new major version, thoroughly test it, ingest it into the Mac App Store, etc.

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:Very Old?

[Lumpy]

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

Re:Very old?

[dgatwood]

You're assuming that the version Apple shipped is vulnerable to that CVE. Has anybody actually verified this? Apple has a habit of silently applying security fixes without pulling in a whole new version, to minimize the risk of inadvertently bringing in changes that break things.

Re:Very old?

[jeremyhu]

> update Xcode's git to a new major version

Where does that nonsense come from?!? There's a git 2.6.6, are you claiming it doesn't contain the security fix?

2.6.6 was released at the same time as 2.7.4. At the time that this vulnerability was announced (March 15), there was no 2.6.6. 2.6.6 was released two days after the announcement of the vulnerability leaving just two days before Xcode 7.3 release (which obviously isn't enough time to build, package, test, ingest, and ship)

If not, that is a major f-up by the git developers.
If it does (which I am fairly sure about since it was released on March 17th, too), Apple really hasn't the slightest excuse to not have shipped a patch within days.

Testing? Qualification? I personally don't want Apple to release software without actually testing it first.

This issue was disclosed at literally the worst possible time for inclusion in Xcode 7.3. Had it been disclosed earlier, it's likely that it could have been fixed in Xcode 7.3.

She's Assuming Naive Devs, Then

[cmholm]

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

That said, I'd argue just about anyone who takes the trouble to install and use Xcode and the associated command line stuff that comes with it is going to know how to steer ($PATH) around (fink, macports) a problematic tool once informed about it.

She got this onto Slashdot, so the hard part is on its way to being handled: getting the word out.

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: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:She's Assuming Naive Devs, Then

[Etcetera]

Are there any other kind?

*rimshot*

There are only three types of people I know who locally develop on Macs:
1) Devs developing a native Mac or iOS application
2) Devs who need to make substantive code changes (or test cycles) when they're off line
3) Devs who don't know how to log in to a remote server to do their development

For #1, you have my sympathies. #2 should go head to a bar, or spend time with the family instead of working after hours. #3 probably need to be hit with a clue-bat, which will hopefully dislodge that "devops" post-it note they've got attached to all their business cards.

Let me get this straight...

[the_other_one]

Does this mean that if your hardware vendor has a deity level above root then that is a bad thing?

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.

Re:Not Apple's Fault

[Trailer Trash]

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.

To be fair to Apple, I typically download the X-Code updates on four or five different Macs here, about 1GB for each one. Multiply that out to all the Macs that are going to download X-Code. It's difficult to imagine the amount of bandwidth that they're burning with each update, it would suck to have to immediately do the same thing again.

Re:Not Apple's Fault

[shawn2772]

Why in the world would they download a complete X-Code replacement to change one small binary?

Re:Not Apple's Fault

[null etc.]

That's how Apple do.

Re:Not Apple's Fault

[shawn2772]

Not true. Many updates are much smaller than the whole package.

Re:Not Apple's Fault

[Trailer Trash]

Not true. Many updates are much smaller than the whole package.

Maybe, but most x-code updates that I get are 1GB+.

Re:Not Apple's Fault

[shawn2772]

Not true. Many updates are much smaller than the whole package.

Maybe, but most x-code updates that I get are 1GB+.

So is your argument that Apple is too technically incompetent to deliver single-binary replacements, much less binary patches? Not buying it.

/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:Simple Fix

[Pikoro]

but my name isn't randalls

Very Old?

[Anonymous Coward]

git 2.6.4 was released about a month before Xcode 7.3 beta was first seeded to developers. How does "one month old" equate to "very old"?

Do you want Apple to update versions of key components after starting the beta process just because the version number changes? git 2.7.0 came out just days before Xcode 7.3 beta1. It makes sense that they'd stick with 2.6.4 as it was a very stable version and there was no compelling reason to update until just a couple days before Xcode 7.3 was released.

Re:9 PERCENT love and attention

[Anonymous Coward]

Or maybe they already jumped on it as soon as it was announced, and it'll be coming out soon in Xcode 7.3.1.

Maybe the reason it wasn't included in Xcode 7.3 was because of the horrific timing of the disclosure to the community and complete lack of disclosure of the vulnerability to companies shipping git.

brew upgrade git

[richardtallent]

$ git --version
git version 2.6.3
$ brew update
$ brew upgrade git
$ git --version
git version 2.8.1

Back to my

Re:brew upgrade git

[Lennie]

Because Slashdot uses MySQL and their collation doesn't allow it ?

Re:brew upgrade git

[jeremyp]

Because it is shit.

Re:brew upgrade git

[jeremyp]

Clarification: "it" refers to the Slashdot software, not beer, your post or Slashdot the organisation.

Clarification on the clarification: The fact that the clarification states that "it" refers to the software only is not meant to imply that the other things listed are definitely not shit.

Re:brew upgrade git

[s122604]

does not work

Might be fixed when Xcode is updated in June?

[Sits]

Sounds like this won't be resolved until Apple releases its next Xcode update (or Command Line Tools for Xcode if you aren't using the IDE). Looking at previous release dates it seems that Apple releases new versions every three months and the previous version was released 21st of March 2016.

Re:Ahahahahaha

[lucm]

iApologist much?

Re: Sunds pretty fishy

[ArsenneLupin]

[not the original poster, just normal reading comprehension...]
(Probably) what he means is "Apple doesn't support more than 3 buttons on mice, unless it's their own overpriced $75 "magic mouse". Button 4 and 5 could be used (for example) for back and forward in a browser"
(Didn't even know that Macs support mice with more than one button, hehe, so 3 is already a neat progress...)

Re:brew install git

[softnewsit]

this is why it won't work https://www.reddit.com/r/netse...

Re:Simple Fix

[Ash-Fox]

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

Re: Sunds pretty fishy

[Aaden42]

Umm. . . USBOverdrive? Works nicely on El Capitan. All 8 buttons on my Logitech are mapped to useful functions.

Even the stock MS & Logitech drivers let you remap the extra buttons if you don’t want to shell out the $20 for USBOverdrive. USBOverdrive lets you setup keyboard & mouse macros per-application which can come in handy.

Re: Sunds pretty fishy

[macwhiz]

Macs have natively supported two- and three-button mice since Mac OS 8 in 1997. Mice with additional buttons work fine provided you have an appropriate driver for them, just like on Windows. If the manufacturer doesn't supply a driver for their extra buttons, there's third-party drivers that work with any USB HID compliant mouse. Logitech gaming mice, with all their buttons, work just fine on Mac OS X. Your troll is out of date...

Re: Sunds pretty fishy

[ArsenneLupin]

Drivers... But what if some "punk" feature on your Mac prevents you from installing any drivers not blessed by Apple?

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?

Apple builds themselves a walled garden

[ComputerGeek01]

Apple builds themselves a walled garden, then utterly failed to prevent a fire from breaking out on the inside. This my friends is sweet poetic justice. A modern OS cannot exist in isolation like these hipster wannabes like to think it can. Apple is not omnipotent and it does not know what is best for you. Every informed Mac user I have ever met bought their system for the same reason, they don't want to take responsibility for their own security. Well guess what, that isn't possible and it never actually was.

sitcom sports closet

[epine]

As I expected, spending 5 minutes typing a simple example to make a point brought the insecure people out of the woodwork.

I take it you're from planet Seinfeld, where even what you manage to learn about life (generally frowned upon) does basically nothing to change your behaviour. In your haste to hew to "simplicity", one large worm MIRVed into multiple smaller worms, and you basically went (inside your own mind) "and the rest is fine print", without a whit of that thought making it to your fingers (heaven forbid that your 5m effort turn into a 5m30s effort).

Technical debt, meet treading-lightly-upon-the-fine-print debt. Back in the seventies, never a closet door was opened on a sitcom without twenty pounds of unused sports equipment cascading down from the storage shelf. And yet, in at least 50% of the buying public, a giant "on sale" tag attached to a racket handle still succeeded in disabling the part of the brain chanting quietly to itself "and where would I put it?"

Some people by nature tend to read the fine print. I'm one of those people, so I know how it goes. It's all too easy to slide into an enabling role, where half your day is spent—for little official credit—helping extract fine-print avoiders from the sports-sock snow pack when the karma closet finally comes tumbling down.

"Gosh, I had no idea snow could be so heavy."

"Would you like some rum with that? I've got this keg thing around my neck."

"I thought those were mechanical gills."

"No, the sound effects are made by a Raspberry Pi. It's actually a keg of rum."

"Wow, you're awfully prepared. I take it you do these rescues a lot?"

"Enough to learn how the pattern goes a hundred times over."

"How does it go?"

"Here's where it starts. Someone tosses off a quick 5m answer, without even noting that fine print exists, even if it only takes an extra ten words."

"But everyone knows that fine print exists."

"To judge by the state of your closet, you're a lapsed Catholic and I'm your indulgence."

"You sound bitter."

"Just a minor side effect of my cellulose diet."

Re:9 PERCENT love and attention

[jeremyhu]

Yes, Apple does need to react to git. Apple does that by updating to newer versions of git in newer versions of Xcode.

The issue here was that this announcement was made at a time when it was too late to include in the March 21 release of Xcode 7.3.

> they don't contribute to it since I'd imagine if they did contribute to it they would have known it was coming

Care to elaborate on why you feel that way? Apple has made attempts to contribute to git only to get shot down and rejected in the past, but most of Apple's changes have since been merged into git upstream or are available for anyone that wants to see them on github.

http://marc.info/?l=git&m=126819399002363&w=4
http://marc.info/?l=git&m=129105538829766&w=4
http://marc.info/?l=git&m=137514771912513&w=4
etc...

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

Re:Solaris RBAC / Shutdown

[Guy Harris]

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

In this particular case, I am the user in question, and I'm lazy enough that I'd prefer to do it from the GUI as I can in Windows and OS X and Ubuntu and Fedora, for example.

Oh, and I can shut down as non-root from the GUI on Solaris 11, too.

(Not that I'm running Solaris 10 much these days; not much platform-specific libpcap/tcpdump/Wireshark development needed there.)

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

+1

Re:Solaris RBAC / Shutdown

[Tenebrousedge]

...I'd prefer to do it from the GUI as I can in Windows and OS X and Ubuntu and Fedora...

The link I gave above gives instructions on how to do that. It requires that you use gdm as your display manager, though. I wasn't able to find any other way to do that, but on the plus side now I have a Solaris VM to play with. I should note that I have no experience with Solaris whatsoever, and only had the article I linked to hand because someone mentioned this shutdown issue in another discussion this week. I'm still sort of incredulous that this kind of UI issue would even arise, but I'm glad they fixed it eventually.

Already fixed in Xcode 7.3.1

[jeremyhu]

FWIW, the developer seed of Xcode 7.3.1 contains git 1.7.4.

Re:Already fixed in Xcode 7.3.1

[Guy Harris]

FWIW, the developer seed of Xcode 7.3.1 contains git 1.7.4.

(Presumably "git 2.7.4".)

Re:Already fixed in Xcode 7.3.1

[jeremyhu]

LOL, yes sorry for the typo. I meant 2.7.4.

Re:Already fixed in Xcode 7.3.1

[jeremyhu]

Well it basically contains 3 full operating systems (watchOS, tvOS, and iOS runtimes).

=/

Just use homebrew

[etinin]

Most decent programmers wil have updated their machine's git version using Homebrew. People who are not capable of doing it, probably won't even be using git in the first place. Also, it's possible to disable Apple's system protection by booting into recovery mode and running one or two commanda, thus giving root it's standard UNIX prerrogatives. Many users, myself included, choose to do this.

Re: Sunds pretty fishy

[Khyber]

"What, you mean the USB HID standard that defines two axes of movement (X and Y) and three buttons?"

Care to point out where it's limited to three buttons? Because my little cheap no-brand 7 button mouse from China has all buttons recognized, no drivers. Perhaps if you understood that the interface standard allows for having the report descriptor changed to show more buttons being present via the mouse firmware (and has been since.. 2001 at least) you might not have made such a crucial mistake.

Very Old?!

[artlogic]

Since when does "very old" qualify as an accurate description of a release that occurred just over 4 months ago? While I believe Apple should fix this (and it shouldn't really be that hard), I think it's a bit disingenuous to characterize what they distributed this way. Especially when Debian is still distributing (patched) 2.1.4!

Re: Sunds pretty fishy

[Plumpaquatsch]

"Mice with additional buttons work fine provided you have an appropriate driver for them, just like on Windows."

I don't even need drivers in Windows.

You probably haven't notice that Windows tends to actually installs drivers from the net every other time you plug in a more-than-three-button mouse. At least when moving between docking stations at work it does. And that's when it actually detects USB mouse and keyboard for a change.

Re:9 PERCENT love and attention

[Plumpaquatsch]

According to MacRumors (and presumably, Apple) and this image: http://cdn.macrumors.com/artic...

Mac Net Sales apparently accounts for just 9 PERCENT of Apple's revenues.

In other words, its Apple's second largest source of revenue, alone bigger than Oracle.