Live data from Hacker News

Remote code execution, git, and OS X

rachelbythebay.com

241–250 of 385 posts

Re: Remote code execution, git, and OS X

#241
post #4

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. Can someone explain it to me?

There were a 2 talks at syscan360 on SIP. I'm still waiting for the slides to come out.

https://www.syscan360.org/en/speakers/

Re: Remote code execution, git, and OS X

#242
post #141
post #22

Earlier quoted context omitted.

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

I wonder what would happen if you did this and then tried to uninstall Xcode

Re: Remote code execution, git, and OS X

#244
post #201

Earlier quoted context omitted.

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 th…

Installing homebrew is a hoop; in an ideal world, your OS vendor would provide a means for installing such packages safely (the Mac App Store would count if Apple cared about it). This is also a bit weird since getting git installed on OSX in the first place requires it's own hoop: "buying" the free copy of XCode and installing it is required for the command line tools that homebrew relies on.

"buying" the free copy of XCode and installing it is required for the command line tools that homebrew relies on.

No, you can simply download the command line tools that Apple provides free of charge - which the homebrew install script in fact does.

Re: Remote code execution, git, and OS X

#245

Earlier quoted context omitted.

$ grep -rc /usr/bin/git /usr/bin/ /usr/local/bin/ /usr/sbin/ /sbin/ | grep -v ':0' | wc -l 0

er.. find /usr/bin/ /usr/local/bin/ /usr/sbin/ /sbin/ |grep -w git

But that merely enumerates pathnames that contain the word "git", not programs that might still invoke the vulnerable version of git directly via "/usr/bin/git".

Re: Remote code execution, git, and OS X

#246
post #178
post #137

Earlier quoted context omitted.

> It will fail. So presumably SIP correctly propagates permissions to all dentries. I'm not sure what's happening then. /usr/bin/git is a small wrapper that invokes the actual git from either the command line developer tools or from xcode (whatever you have selected with `xcode-select`)

Right, so XCode subverts the security of SIP intentionally? That's ... dumb.

I don't think it's intentional subversion. AFAIR, having command line wrappers in /usr/bin pointing to command line tools or xcode tool chain predates SIP. If anything, protecting developer tools was either neglected, or changing the concept of how it works to suit SIP was deemed not worth the cost.

I mean, SIP is generally only partial protection anyway, isn't it?

Re: Remote code execution, git, and OS X

#247
post #188
post #155

Earlier quoted context omitted.

If you're going to rewrite in any case surely it's worth going to Rust (or Ada, or another language that simply doesn't have the myriad unsafe possibilities that C++ does).

There are many arguments to be made in favor of C++, such as talent availability, experience from other porting projects, the possibility of doing incremental porting, etc. My impression is that some projects are already experimenting with or using C++ in their C code bases, so C to C++ is quite likely.

But if the goal of the rewrite is safer tooling then Rust wins.

Re: Remote code execution, git, and OS X

#248
post #178

Earlier quoted context omitted.

Right, so XCode subverts the security of SIP intentionally? That's ... dumb.

I don't think it's intentional subversion. AFAIR, having command line wrappers in /usr/bin pointing to command line tools or xcode tool chain predates SIP. If anything, protecting developer tools was either neglected, or changing the concept of how it works to suit SIP was deemed not worth the cost. I mean, SIP is generally only partial protection anyway, isn't it?

I meant installing the actual binary executed into a non-protected directory. What is the point of having SIP if the only process that can bypass it (the App Store installer) doesn't break the code.

Yes, I know that wrappers isn't new. But if they wanted to secure it they could've kept the actual binary in a SIP-protected directory.

Re: Remote code execution, git, and OS X

#249
post #219
post #170

> They are basically screwed until Apple deigns to > deliver a patched git unto them Actually, no. Don't use the tools that come pre-installed. All you have to do* is: brew install git *and make sure that brew installs are prioritised in your $PATH. Which you should do anyway.

This doesn't prevent someone from writing "/usr/bin/git/" into their OS X exploit.

If someone can get you to run their code, they don't need the git vulnerability

Re: Remote code execution, git, and OS X

#250

Earlier quoted context omitted.

Except for those who have used it and refuse to use it again. There are prebuilt binaries of up to date git distributed via .pkg. The yeast infection that is Homebrew is unnecessary

That's kind've harsh. What's the issue? Homebrew was about the best option that's existed on OSX for a few years now I thought...

Personally I use MacPorts.
Post reply on HN