Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Remote code execution, git, and OS X

rachelbythebay.com

Post reply on HN
Print view View original

201–210 of 385 posts

Re: Remote code execution, git, and OS X

#201

Post by pyre »

efdee wrote: post #164
matt4077 wrote: post #140

Earlier quoted context omitted.

There really isn't a hoop tp jump through... Everyone uses homebrew, which happens to work extremely well (to the point where it's apparently being ported to linux now – go figure). With the homebrew git installed, the stars really have to align for that vulnerability to be exploited. You can possibly get a user to clone from your repository. But if you can also get him to use the git version you want, we're at the p…

Claiming this isn't a hoop to jump through is Apple fanboyism at its best.

Really? Talking about how homebrew is pretty painless is "Apple fanboyism at its best?" Sure it's another thing to do, but look at any thread about running Linux on a laptop. How many people are like X laptop runs great you just need to add Y kernel parameter to the boot options. Isn't that a "hoop to jump through" too? Or all of the people fighting to keep their Windows install from upgrading to Windows 10. Isn't that a hoop to jump through?

Re: Remote code execution, git, and OS X

#202

Post by pyre »

bertan wrote: post #120
dchest wrote: post #34

Earlier quoted context omitted.

This is in the linked post. Do this to disable it: sudo chmod -x /Applications/Xcode.app/Contents/Developer/usr/bin/git

sudo cp /Applications/Xcode.app/Contents/Developer/usr/bin/git /somewhere/to/backup/just/in/case sudo rm /Applications/Xcode.app/Contents/Developer/usr/bin/git sudo ln -s /usr/local/bin/git /Applications/Xcode.app/Contents/Developer/usr/bin/git

Is the git binary where the vulnerability is... or is it in one of these:

  $ ls $(git --exec-path)

Re: Remote code execution, git, and OS X

#203

Post by zwarag »

matt4077 wrote: post #140
Fuxy wrote: post #110

Earlier quoted context omitted.

It's times like this that prove I made the right choice sticking to Linux. There's nothing I hate more than the inability to fix things that are broken on my system or the fact that I would have to jump trough a lot of unnecessary hoops to do it. The few small advantages are just not worth it in the end for me.

There really isn't a hoop tp jump through... Everyone uses homebrew, which happens to work extremely well (to the point where it's apparently being ported to linux now – go figure). With the homebrew git installed, the stars really have to align for that vulnerability to be exploited. You can possibly get a user to clone from your repository. But if you can also get him to use the git version you want, we're at the p…

> Also: I'd hate if I had to fiddle around with kernel parameters to get printing, sleeping, networking, waking, font-displaying, account-switching, video-playing, time-knowing or up-backing to work every time canonical decides it's time for a new subsystem. I love linux on the server, but maintaining a function desktop system is simply a waste of time. A somewhat evil waste of productivity, actually, because it feels like work and at the same time provides those frequent little victories that can turn it into an obsession.

On the other hand. Once you master this (which is not such a huge intend), you know your system.

Which is a valuable "smart skill" when developing (even web apps). For example, knowing how to use awk and sed instead of having to start a node or ruby instance is a thing that shows a developer actually knows how to run linux and not only "how to run stuff on linux".

You'll also understand $PATH. Which apperently is a thing most MAC users do not understand. Having to start "docker-shell" because they don't know how to extens theyr $PATH is a freaking joke and a workflow killer.

I understand that MAC's are comfortable to use and maintain. But as developers we should embrace leaving the comfort zone and face the real deal. We shouln't be some bunch of kids who need mac because it's comfortable.

Lets grow from little kids that need "mama mac" to take care of our stuff and become grown up's that can handle a system, because they know the system.

Re: Remote code execution, git, and OS X

#204

Post by stuff4ben »

efdee wrote: post #164
matt4077 wrote: post #140

Earlier quoted context omitted.

There really isn't a hoop tp jump through... Everyone uses homebrew, which happens to work extremely well (to the point where it's apparently being ported to linux now – go figure). With the homebrew git installed, the stars really have to align for that vulnerability to be exploited. You can possibly get a user to clone from your repository. But if you can also get him to use the git version you want, we're at the p…

Claiming this isn't a hoop to jump through is Apple fanboyism at its best.

Would much rather have a system that just worked but required a "hoop to jump through" in order to use git, vs the multitudes of hoops you have to jump to in order to get a Linux desktop system functional in a corporate environment.

At home when I'm futzing around I don't mind (and quite enjoy it). But at work I don't have time to diddle my device drivers and OMG the xorg.conf crap I had to deal with in the past that still give me nightmares...

Re: Remote code execution, git, and OS X

#205

Post by Manishearth »

anu_gupta wrote: post #128
chris_wot wrote: post #123

Earlier quoted context omitted.

Not if I want to update system software for some reason and I'm running a server.

So you install development tools like XCode on a server?

We use a mac server as a build machine. It's pretty annoying; given that you need to graphically log in to accept a license every now and then to use lldb (a non-graphical debugger) among other things.

In our case I think rebooting the server works, but you can't be aware of all usecases.

Re: Remote code execution, git, and OS X

#206

Post by [deleted] »

chris_wot wrote: post #196
anu_gupta wrote: post #189

Earlier quoted context omitted.

> Incidentally, calm down a bit - you sound pretty outraged yourself! This seems to be your pattern when you get upset. You've told someone else they were being defensive, now you're saying I need to calm down. I guess that's easier than rebooting a server and turning off SIP.

I'm more amused than upset. You seem rather steamed up there though... Now how about answering my actual question. What if I don't want to turn off SIP but I want to use dtruss to troubleshoot my system? If Apple truly doesn't want me to use dtruss, then why do they bundle it?

[deleted]

Re: Remote code execution, git, and OS X

#207

Post by [deleted] »

chris_wot wrote: post #196
anu_gupta wrote: post #189

Earlier quoted context omitted.

> Incidentally, calm down a bit - you sound pretty outraged yourself! This seems to be your pattern when you get upset. You've told someone else they were being defensive, now you're saying I need to calm down. I guess that's easier than rebooting a server and turning off SIP.

I'm more amused than upset. You seem rather steamed up there though... Now how about answering my actual question. What if I don't want to turn off SIP but I want to use dtruss to troubleshoot my system? If Apple truly doesn't want me to use dtruss, then why do they bundle it?

[deleted]

Re: Remote code execution, git, and OS X

#208

Post by acdha »

chris_wot wrote: post #125
comex wrote: post #114

Earlier quoted context omitted.

Yes. This is by design, since the whole point is to defend against malware that has gotten root privileges; requiring recovery mode ensures that the physical user of the computer consents to the change.

Wow, my innocent question seems to have pissed off a few people! Anyway, so only system updates can update the OS X system? Which involves a system reboot? How does the "system protected" software get updated? But not making it easy to update flawed software sounds like a great vector for malware.

They didn't change the user experience in any way - most updates do not require a reboot, the ones which do are fast - so I'm guessing that the kernel checks the code signature on the process doing the write when deciding what to block and possibly even requires a valid Apple signature on the new file.

Re: Remote code execution, git, and OS X

#209

Post by acdha »

Manishearth wrote: post #205
anu_gupta wrote: post #128

Earlier quoted context omitted.

So you install development tools like XCode on a server?

We use a mac server as a build machine. It's pretty annoying; given that you need to graphically log in to accept a license every now and then to use lldb (a non-graphical debugger) among other things. In our case I think rebooting the server works, but you can't be aware of all usecases.

Try:

    sudo xcodebuild -license

Re: Remote code execution, git, and OS X

#210

Post by Kristine1975 »

So if I understand correctly:

1. OS X ships with a "git" command in /usr/bin that merely looks for the real "git" command inside Xcode or somewhere else and executes it.

2. The vulnerability is inside the real "git" (shipped with Xcode/the Command Line Tools) that Apple apparently cannot be bothered to update.

3. The author complains about not being able to make /usr/bin/git non-executable because of SIP.

Why not just make the real "git" command non-executable and be done with it?

And since /usr/bin/git apparently just delegates, the git vulnerability at least won't endanger most users, since they don't have the real (old, vulnerable, thanks Apple) git installed.

Post reply on HN