
Running and disguising programs through XCode shims on OS X - chris_wot
http://randomtechnicalstuff.blogspot.com/2016/05/os-x-and-xcode-doing-it-apple-way.html
======
eridius
> It bypasses SIP

No it doesn't. Why are you claiming it does? /usr/bin/git and the other shims
are behaving precisely as expected. There is absolutely no violation of SIP.
Someone who is able to muck with DEVELOPER_DIR or install a fake xcrun does
not gain any privileges by doing so, and they're already in a position to do
whatever malicious act you're thinking they'd trigger by invoking
/usr/bin/git.

~~~
chris_wot
The reason they designed SIP was partially to prevent anyone from replacing a
binary with one of their own.

Because of the way that they have put in those shims, you can - without being
root - install a binary (or a shell script) in a user directory that acts as
if it was another program - the example I used is git.

(Interestingly, they chose to use a purpose built library to do this. Their
git shim literally just checks an environment variable and calls on a library
function to execute xcrun. I do wonder why they chose to write a program in a
compiled language instead of using a shell script. A passing thought was that
they didn't really want to publicise what they had done because they knew most
BSD fans would probably throw them brickbats... but then again, Apple seem to
be fans of binaries so it was probably not done to obfuscate anything...)

When you say that someone who is able to change DEVELOPER_DIR or install a
fake xcrun is already in a position to do whatever malicious act they feel
like, then this is precisely the reason why Apple implemented SIP. (I am
curious why you think they prevent access to those directories even by root
though...)

A big part of SIP is preventing the end user from typing in their password to
give a malicious program access to replace certain binaries installed in the
/usr/bin directory (and a few other locations). So basically they don't want
git, or any other program, to work in a way they didn't intend - i.e. They
don't want malware authors installing a riot kit by replacing binaries.

In essence, this is what this is doing. The main difference here is that
instead of them needing to be root, they just create a directory, create a
small script update an environment variable and optionally tweak .bashrc as
the user and they have effectively added a wrapper to the XCode utility. With
no need to elevate privileges.

I'm sure you can see that is problematic?

~~~
eridius
They designed SIP to prevent anyone from modifying the operating system. And
they designed the shims to operate in precisely the manner they did. I still
don't understand why you think the correct operation of the shims is somehow
breaking SIP, because it's not. When using the shims even with a fake
developer dir, the operating system files are not modified, and the shims are
working precisely as documented.

> _A big part of SIP is preventing the end user from typing in their password
> to give a malicious program access to replace certain binaries installed in
> the /usr/bin directory (and a few other locations)_

And that hasn't changed. The binaries are not being replaced.

> _So basically they don 't want git, or any other program, to work in a way
> they didn't intend - i.e. They don't want malware authors installing a riot
> kit by replacing binaries._

No, they don't want malware authors to modify the operating system. Doing a
non-privileged action (i.e. setting the env variable) in order to change the
behavior seen when invoking /usr/bin/git really has no relation to SIP at all,
that's jut working as intended. Besides, nothing of the behavior you describe
has anything to do with root kits either. Someone who can point DEVELOPER_DIR
at a malicious directory hasn't gained any privileges by doing so, and has not
compromised the operating system in any way.

> _In essence, this is what this is doing. The main difference here is that
> instead of them needing to be root, they just create a directory, create a
> small script update an environment variable and optionally tweak .bashrc as
> the user and they have effectively added a wrapper to the XCode utility.
> With no need to elevate privileges._

And without _gaining_ any privileges. I've already said this multiple times
before. The end result of all of this is they have no more privileges than
they already needed to set this up in the first place. They've gained
literally nothing from doing this.

> _I do wonder why they chose to write a program in a compiled language
> instead of using a shell script._

Probably so they can codesign the binary, since you can't codesign shell
scripts.

------
chris_wot
Sorry about some of the formatting, especially on mobile devices. Blogger is a
bit... special... When it comes to line breaks and spacing :-(

