Live data from Hacker News

Remote code execution, git, and OS X

rachelbythebay.com

141–150 of 385 posts

Re: Remote code execution, git, and OS X

#141
post #22

Isn't this why projects such as Homebrew thrive? For me personally, I just `brew install git`, and I keep it updated that way (`brew update && brew upgrade`)... Sure, Apple should ship a fix, but there are ways around it for now.

Sure, but your /usr/bin/git is still vulnerable. You're one config mistake (or maybe running a "malicious" script) away from executing.

Why not replace XCode with brew version entirely:

  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

Re: Remote code execution, git, and OS X

#142
post #89

Same as always. Apple only care about security when people start screaming. I can't wait until a worm or similar wide-spread disaster hits the Apple eco-system and just deletes the system when it's done spreading.

So ... has anybody actually checked to see if Apple has patched the vulnerability in git without bumping the version number, like pretty much every linux distribution does for their stable releases?

HN users checked for backports and said "doesn't look like they did".

Re: Remote code execution, git, and OS X

#143
post #89

Earlier quoted context omitted.

So ... has anybody actually checked to see if Apple has patched the vulnerability in git without bumping the version number, like pretty much every linux distribution does for their stable releases?

You're joking, right? When I use software and I look at the version number, I like to know that it is what it says it is. If they are going to patch the vulnerability, then I want to know if they have done so. Besides which, this whole question is missing the point somewhat. There is no easy way of updating the system supplied tools like git, even if you wanted to. The latest version of git is v2.8, and I think it wo…

>The latest version of git is v2.8, and I think it would be grand if we could use a version less than 6 months old!

Exactly. Apple are update nazis themselves (support for old versions is being dropped quickly and users are forced to update), so they should at least apply the same logic to system tools.

Re: Remote code execution, git, and OS X

#144
post #124
post #46

Earlier quoted context omitted.

The Homebrew installation process uses the system git.

Can you inunstall XCode again once you have installed a compiler, toolchain, and git via Homebrew?

You can just install the command line tools without xcode. From those tools, most can be replaced with their homebrew versions so you only need them for bootstrapping. But if you want to do hardware- or OS X related development, you will need to keep the tools around. CUDA, for example, needs clang et. all.

They don't take much space, though, and the toolchain is treated a bit better by Apple than utilities like git, vim etc.

Re: Remote code execution, git, and OS X

#145
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…

The stars don't really have to be aligned: any script could invoke system git directly.

Re: Remote code execution, git, and OS X

#146
post #112

Earlier quoted context omitted.

You're joking, right? When I use software and I look at the version number, I like to know that it is what it says it is. If they are going to patch the vulnerability, then I want to know if they have done so. Besides which, this whole question is missing the point somewhat. There is no easy way of updating the system supplied tools like git, even if you wanted to. The latest version of git is v2.8, and I think it wo…

Inability to manually update the copy of a tool located in /usr is par for the course with most Linux distributions - in that case the kernel won't stop you from replacing the files (unless your distro has the root FS mounted RO), but the package manager will typically replace them right back the next time there's a minor update (same for OS X updates pre-SIP), and it's easy to accidentally break things. Instead, the…

With Linux you don't have this problem at all.

1. add a repository with up-to-date version

2. update the system

It couldn't be any simpler.

Re: Remote code execution, git, and OS X

#147
post #129

Earlier quoted context omitted.

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.

Sorry if I came across that way myself. As for updates - I'm not sure; I should figure that out when I have the chance.

:-) all good - I'm more curious to know how Apple updates their operating system. Evidently it's possible to modify these protected files, I'm now curious how they do it.

Best I can find is the following article:

https://reverse.put.as/2015/10/12/rootfool-a-small-tool-to-d...

Re: Remote code execution, git, and OS X

#148

Earlier quoted context omitted.

You are missing the wider point I fear. You seem to be so focused on git that you miss the point that there are other system utilities that are installed in /usr that you might need to patch. And if I want to troubleshoot something odd, it would be nice to be able to hook in dtrace - without rebooting the server, flipping a switch to disable the "feature", and then troubleshoot my server's issue.

No, I'm just bored of faux-outrage and agenda pushing. If this is such a critical issue, then reboot your Mac and disable SIP. 5 minutes and done. In the time it's taken you to post all your comments here, you could have fixed it. [edited to add] It's not like SIP was a secret - it was one of the major features of El Capitan. Didn't you do any research before upgrading your mission critical server to El Capitan?

You read into what is not there. I know about SIP already, but I've always been surprised about it as it seems pretty flawed to me - it turns out if you can get root access you can easily bypass the "protection" mechanism with a small utility that loads up a kernel extension and bypasses the mechanism anyway.

https://github.com/gdbinit/rootfool

Incidentally, calm down a bit - you sound pretty outraged yourself!

You might want to address the dtrace issue though - let's say you didn't want to disable the protection that SIP provides in making the /usr filesystem immutable. How do you then run dtrace on system utilities when troubleshooting?

Genuinely curious how you answer that.

Edit to ask another question: another question for you, as you seem to have the answers here: why does Apple install git in a directory that is under the control of System Integrity Protection? Why not under /usr/local? It's not exactly a "system utility" - it's a DVCS and not in any way critical to the running of the system. Hell, I'd not even consider it system software.

And how does Apple do this? The last time I installed the XCode command line tools, I don't recall that I had to reboot my system, so it looks like Apple do indeed have an update mechanism to overwrite the files. In which case it is one exploit away from disabling the file immutability protections afforded by SIP...

Re: Remote code execution, git, and OS X

#149
post #103
post #76

Best part: > 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.)

I looked at the offending function, and it would be trivial to rewrite it in C++ in an easy to understand and safer way. It probably wouldn't be as safe as Rust, but still a lot better. A lot of Linux C utilities would benefit from such a treatment.

A rewrite in C++ would not make it any safer. Rewriting it to make it easier to understand could make it safer, but you do not need a different language for that.

Re: Remote code execution, git, and OS X

#150
post #11

Isn't this why projects such as Homebrew thrive? For me personally, I just `brew install git`, and I keep it updated that way (`brew update && brew upgrade`)... Sure, Apple should ship a fix, but there are ways around it for now.

It's a bit too precarious to be an adequate solution, in my opinion. It depends on /usr/local/bin always being ahead of /usr/bin in $PATH, and on scripts never invoking the system git via its full path, and on Homebrew never accidentally uninstalling git due to a botched upgrade. Not to mention the fact that Homebrew itself uses the system git to install itself.

When would the order of $PATH vary?
Post reply on HN