Jeff Johnson

(replying to Saagar Jha)

@saagar Could you be less vague? You said it was a reminder, but I’m not reminded of anything, and if I’m not, then I’m not sure who would be.

AssertionError("Joe Groff")

(replying to Jeff Johnson)

@lapcatsoftware @saagar not sure exactly what saagar is thinking of, but there are various entitlements which grant an executable root-like abilities as a normal user, and without sip, not much is there to stop a malicious process from granting entitlements to other executables under its control

Saagar Jha

(replying to AssertionError("Joe Groff"))
@joe @lapcatsoftware Exactly this. The post above was a reference to the time Apple accidentally allowed anyone to log in without a password which of course did not involve SIP at all

Jeff Johnson

(replying to Saagar Jha)

@saagar @joe I’m confused. Are you referring to the High Sierra “I am root” bug, which you admit that SIP did not protect against? If so, then why would you mention that in this context? It’s a red herring and feels obscurantist.

So far, neither you nor Joe have given a single specific example, which again, is a reminder of absolutely nothing.

1 replies →
1 replies

AssertionError("Joe Groff")

(replying to Jeff Johnson)

@lapcatsoftware @saagar i didn't have an exploit per se in mind, but one thing i was recently playing with in a side project was creating virtual network interfaces with vmnet.framework. creating an interface typically requires root, but if apple grants your executable the `com.apple.vm.networking` entitlement, then that executable can do so as a regular user, or even in the sandbox. but the mechanisms that ensure can grant that entitlement rely on SIP, AIUI

AssertionError("Joe Groff")

(replying to AssertionError("Joe Groff"))

@lapcatsoftware @saagar i suppose that isn't so different from setuid binaries though

Saagar Jha

(replying to AssertionError("Joe Groff"))
@joe @lapcatsoftware Yeah I mean vaguely you would have the same issue if there was a configuration that convinced ld to let you preload into a setuid binary or that you could mess with their procfs or something

Jeff Johnson

(replying to Jeff Johnson)

@saagar @joe I respect your technical knowledge, but explaining it to other people is a different matter.

I’ve spent a lot of time and effort over the years trying to explain things to people, for example on my blog.

You seem to assume that people know what you’re talking about, but frankly, they usually don’t.

Saagar Jha

(replying to Jeff Johnson)
@lapcatsoftware @joe I was joking because I assumed you were as well by asking whether there were any defenses before SIP. I figured the answer to this was obvious; a system without SIP that lets you instantly escalate to root would be considered broken.

Saagar Jha

(replying to Saagar Jha)
@lapcatsoftware @joe This is a reminder because I’ve been saying this for a while to various people and it’s not even something I wrote about first, https://gist.github.com/ChiChou/e3a50f00853b2fbfb1debad46e501121 is a good early example. They are not super hard to find and easy to “exploit”
1 replies →
1 replies

Jeff Johnson

(replying to Saagar Jha)

@saagar @joe I got an AppleScript error, NSXPCConnectionInterrupted, perhaps because it’s running the script as Setup Assistant.

But I’m presuming that the vulnerability is the ability to create a new admin user with known password, and the specific exploit is inessential?

1 replies →
1 replies

Saagar Jha

(replying to Jeff Johnson)
@lapcatsoftware @joe Yes. In fact the ability to create a new admin user is also just an example, there’s plenty of undesirable things you can do that this model breaks under. I would imagine bypassing TCC is probably not too difficult with SIP disabled for example

Jeff Johnson

(replying to Saagar Jha)

@saagar @joe Bypassing TCC is never too difficult. ;-)

In any case, I still struggle to see how the situation with SIP disabled is worse than the situation with SIP nonexistent. Perhaps you’re overestimating past security?

Jeff Johnson

(replying to Jeff Johnson)

@saagar @joe How did Setup Assistant app work in Mac OS X 10.10 and earlier, though?

Saagar Jha

(replying to Jeff Johnson)
@lapcatsoftware @joe I assume it was just being run manually, I think that particular avenue might be blocked now due to launch constraints. I do know I have used either this or something else I found during a CTF to cheese another kernel pwn challenge though

Jeff Johnson

(replying to Saagar Jha)

@saagar @joe What I meant was, how was Setup Assistant NOT vulnerable in Mac OS X 10.10 and earlier? Which goes back to my original question, there was a defense before SIP?

Jeff Johnson

(replying to Jeff Johnson)

@saagar @joe I have an old Mac with Snow Leopard, and I can DYLD_ inject Setup Assistant.

The app quits on its own after launch for whatever reason, perhaps because it was designed to run only once.

Saagar Jha

(replying to Jeff Johnson)
@lapcatsoftware @joe I think Library Validation was introduced before SIP but not way back in 10.6

Saagar Jha

(replying to Saagar Jha)
@lapcatsoftware @joe To be clear I am not saying that 10.10 was secure I just don’t think the current state is exactly the same as what we had back then

Jeff Johnson

(replying to Saagar Jha)

@saagar @joe Library validation was introduced in 10.10. That’s the point, though: it’s independent of SIP.

The question is whether disabling SIP is worse than not having SIP, and I’m not sure that it is. You seem to blame SIP for the introduction of a root escalation, whereas I wonder whether it was preexisting.

Saagar Jha

(replying to Jeff Johnson)
@lapcatsoftware @joe It’s more nuanced than that. If there’s a security bug, and we assume Apple will get around to it someday, without SIP they would fix it in some other way. Wi5 SIP, that is the way they consider it fixed.

Jeff Johnson

(replying to Saagar Jha)

@saagar @joe "we assume Apple will get around to it someday"

I don't assume that. ;-)

In any case, it's merely hypothetical speculation. There's no real-world argument that disabling SIP is worse than pre-SIP without real-world examples of post-SIP bugs.

Also, Apple can be publicly pressured. Disabling SIP is supposed to be an outlet for "You can always choose to run any software on your system," which becomes a lie if Apple sabotages that.

Saagar Jha

(replying to Saagar Jha)
@joe @lapcatsoftware I don’t expect you to know the complete anthology of my posts and I’m happy to explain but I didn’t give specifics earlier not to be annoying but to avoid the idea that if Apple patches this one way to do it the problem is solved. It’s a general issue.