Saagar JhaThis is your reminder that having SIP turned off allows trivial escalation to root and disabling part of SIP is broadly equivalent, security wise, to disabling the whole thing
Amy@saagar genuine question, how dumb is "i am already fucked if malware runs as my regular user, so idc about escalation or persistence"? it has kind of always been my stance as a casual user but i suspect im missing something
@a I largely agree but a lot of people don’t and I feel they ought to understand what they are doing
Jeff Johnson@saagar It’s broadly equivalent to running Mac OS X 10.10 and earlier.
@saagar Why not?
@lapcatsoftware SIP is now the only line of defense for many things
@saagar There was a defense before SIP?
@lapcatsoftware Assuming they didn’t just let you log in without a password sure
@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.
Joe Groff (1M Context)@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
@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
@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.
@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.
@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.
@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”
@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.
@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
@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
@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
@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
@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
ran mak@saagar @lapcatsoftware none of this makes any sense. if it's trivial, what's the way? i'll report it as a bug.
if you can't tell me what it is, is it a zero day? are reminding us that there are 0-day vulnerabilities at any given time?
only macos uses SIP, so you're saying everyone else is insecure or macos is insecure by design ?
@ranvel @lapcatsoftware What Joe said here: https://f.duriansoftware.com/@joe/116134278291526557. There are always a handful of these present at any given time, and Apple does not consider them bugs because they view SIP as a security boundary so any report that starts with “first, disable SIP…” is discarded
Joe Groff󠄱󠄾󠅄󠄸󠅂󠄿󠅀󠄹󠄳󠅏 (@[email protected])
@[email protected] @[email protected] 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
@ranvel @lapcatsoftware Other platforms are often really broken which is well documented online but my point here is really that macOS can be even more broken if SIP is off because the default is that you are supposed to have it on. There are designs that require its existence
@lapcatsoftware @ranvel Put another way, the design of SIP makes it possible to architect security boundaries that are not possible on other systems, but when you take away the protection, they fail in completely different ways. It’s an orthogonal security feature
@lapcatsoftware @ranvel On another OS, code running as your user cannot perform privileged actions because, well, that would give you that privilege. On macOS code running as you but written by Apple can do whatever it wants and SIP is effectively what enforces this
@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.
@ranvel I am generally of the opinion that Apple should open AMFI trusted keys to third party developers
tbodt@saagar allowing untrusted kexts though? given that changing a kext requires reboot and auth just like disabling sip?
@tbodt I don’t think there is an easy way to install a kext but given that I basically never do this I doubt anyone really cares at this point
@saagar i mean like, if you partially disable sip to load a kext, and that kext is safe, and you never change it, that's better security-wise than sip fully disabled. right?