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.