@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 #OnlyApple can grant that entitlement rely on SIP, AIUI

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

@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?

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

@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

@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?

@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.

@lapcatsoftware @joe I think Library Validation was introduced before SIP but not way back in 10.6

@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

@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.

@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.

@saagar I don't know, I think this entitlement thing falls firmly outside of "trivial" anything. Can I still inspect the entitlements of the software in this scenario ? I don't think people who are disabling SIP are running cracked executables or not using other precautions. I personally use Mother's Ruin's Suspicious Package & Archaeology and I regularly audit anything that is persistent with Lingon Pro and Launch Control.

I need to have SIP off because I use dtrace frequently. If you have an odd problem occuring right now in the currently running environment, and it is an intermittent issue, then you can't really restart and temporarily disable SIP.

I think what people who say SIP should always be on are saying "I don't think you have any reason to be running dtrace". I think that is a bold assertion and that's why I replied. I think in the context of your followers, we would be more prone to using dtrace than the general population.

Finally, I understand what you mean when you say "There are always a handful [of these trivial workarounds] at any given time". I believe there may be workarounds at any given time, but I doubt they are trivial. But the other important point about this is that you recognize that these issues are indeed being fixed, and that the revolving door of bugs surrounding this always keeps a few unresolved issues. I think these reports may be deprioritized, but not discarded completely.

@ranvel I’m not making a moral judgement of whether you enable SIP or not. I just think you should have an appropriate perspective of the risks you take when you enable it and what Apple considers to be their security model.

@ranvel I linked this in another thread but I’ll also share here to let you decide for yourself whether this is trivial or not: https://gist.github.com/ChiChou/e3a50f00853b2fbfb1debad46e501121. There are definitely more; I don’t track them closely because they’re not very interesting except as a party trick

@ranvel The key takeaway here is that Apple doesn’t consider that a bug (and, while annoying in general, I kind of understand why) so they’re not obligated to fix this kind of thing, and the shape of this looks very common to me (“system service talks to unprivileged thing”)

@saagar yeah, this is good stuff and i didn’t know about this. i haven’t examined the exploit too closely, but i get what it is doing. i would have expect that flippancy internally, but to get that as a response to a legitimate security concern means that i should probably think hard about what you’ve advised.

i think, unfortunately, this is a reality vs. ideal situation. this is not the security model we want: the tools for evaluation (dtrace) are blocked philosophically and logically by SIP. but, when you disable SIP, you’re not thinking about typical ACLs, you need to go to `dyld`, because for apple-signed (or those with the entitlement) executables it behaves differently.

there are a lot of red flags there.

but also, you have done the rare thing of convincing someone on the internet that they need to reconsider their views.