It's a bit odd that the response here is to patch every single XPC service individually. This feels like some kind of design issue in the sandbox itself. Why are so many XPC services that are clearly intended to be app private reachable from sandboxed apps?
Nice work.
I wonder whether we are on the right track with such architectures though. It seems with every security framework envisioned to combat some set of attacks, a whole new class of issues pop up. And I don't _feel_ like things are more secure in the end.
A bit like dutch tax law, it is just a stack of patches to fix exploits and it might have achieved consciousness already! ;)
MacOS (ie NeXTstep) was built from the ground up to be an open and extremely extensible OS.
There were countless ways to add in some 3rd party extension or hook. Since there were multiple runtimes to access your software, it was actually an impressive technical feat at the time to have it all work together seamlessly.
Java, classic Mac, X11, and the NeXTstep codebases all ran together without issue due to several of the kernel's extensible entry-points.
On top of that, the platform had APIs that let apps talk to each other without issue.
However, little by little, Apple has backtracked on that philosophy and continues to close the system down. Quite a fascinating journey.
Impressive finds! As you allude to in your post, it seems very likely similar flaws still exist in the wild. I’d imagine we are going to see a consistent stream of XPC related CVEs unless Apple is redesigning its approach to hardening those services.
They're great second line of defence, but large organisations tend to reject fixing RCE when you are not able to escape sandbox and so anything meaningful, so they use them as main line of defense and that makes me sad.
O/t but if any sandbox experts know of strategies to get around the maximum "pattern serialization length" limitation, this issue has been driving me nuts for quite a while: https://github.com/NixOS/nix/issues/4119
Unfortunately sandbox-exec isn't really documented (and supposedly deprecated?) so trying to sort this out is a bit of a headache.
There's an endless stream of bypasses on macOS, because the operating system was never designed for these granular permissions. You can't just add them later, on top of the legacy Mac OS and NeXTSTEP technologies.
I've found a number of bypasses myself, and I'm not even a security researcher, just a longtime app developer. I know where the bodies are buried, so to speak. However, I ultimately gave up looking, because Apple's security vulnerability reporting system is absolute trash; their only interest seems to be to keep you quiet for as long as possible. It's a waste of time.
My overall feeling is that macOS has become the victim of security theater, harming both users and legitimate developers with enfeedbled software and an endless stream of permissions requests—much like Apple's old parody of Windows Vista—while doing nothing to stop real attackers, who can easily bypass the security theater whenever they want.
those overlooked xpc services in the pid domain are a clever way to bypass sandbox limits on macos. that dyld injection trick to dodge entitlement checks is slick. apple’s patching here feels kinda bandaid-y—maybe they need a real overhaul on how sandbox inheritence works?
This is, unfortunately, the sort of thing that motivates QubesOS. We are, as humans writing code, not good at complexity, and as Apple's lockdown mode admits, parsing complicated stuff, even when you design security boundaries around it, is hard to do properly. Lockdown just punts a ton of complexity entirely out of the system, and the tradeoff is rather substantially improved security against a wide class of attacks.
QubesOS design philosophy is essentially, "Everything in a booted OS image must be assumed to be able to, some way or another, access everything else in there." So you have various silos that have extremely limited communication between them (you can "push" from one VM to another, but you can never "pull" from another VM, the framebuffer is simple, etc). You're totally free to add sandboxing as useful, but it's not considered a full security boundary. Hardware virtualized VMs are, on a fairly stripped down Xen that removes a lot of attack surface in terms of legacy device emulation and other features they don't need.
Apple has done a lot of security focused improvements over the years, but modern computers and OSes are just so complicated that even they struggle to get it right regularly. And the attackers only need one mistake to achieve their goals. :(
//EDIT: As far as practicality goes, I do daily drive QubesOS as my main computer on a 2C/4T laptop with 16GB RAM - old X250. There are plenty of things it's not great at, but I'm not heavy on the "videos or video games" thing anyway. Dual booting for gaming is an option, as is a separate desktop that doesn't do anything important for gaming, but you don't need some monster machine to do practical things with Qubes. I can't have a thousand browser tabs open, but I don't do that anyway, I browse "JITless" (disable Javascript JIT as it's a ton of attack surface that's regularly exploited), and... it's a less-intense form of computer use than standard, but it also means I don't have a desire to spend all my time on a computer.
Let us simplify our IT layers and stacks before it is too late.
It's time to introspect and ask those critical questions: Is it really necessary to install each one of these apps, every single one of these libraries and frameworks? How can I remove dependencies from these libs and do a little core work myself? And tell the same thing to your partners, colleagues, coworkers, etc. If you find 4-5 apps doing basically the same thing (like communication or productivity tool), see if you can consolidate them into one.
Maybe it's time Apple admit that maybe next-gen AV has a place on the Mac platform, and not rely on the current model of hope and good vibes to mitigate new attacks. This includes not allowing their community moderators to continue to gaslight customers into thinking all security software is bad and that their OS is invincible with 2000s-era propaganda on their support forums.
> According to Apple, “CVEs are only assigned to software vulnerabilities previously released to production and not to vulnerabilities for beta-only software.” This vulnerability only affects the macOS Sonoma Beta version.
IOW it's a fascinating read into security research and macOS architecture, but only pertains to a beta release of the previous major version.
(edit: I stand corrected, there's multiple vulns as TFA's very title says, and some may still be pertinent)
Multiple new macOS sandbox escape vulnerabilities
(jhftss.github.io)579 points by transpute 8 November 2024 | 190 comments
Comments
There were countless ways to add in some 3rd party extension or hook. Since there were multiple runtimes to access your software, it was actually an impressive technical feat at the time to have it all work together seamlessly.
Java, classic Mac, X11, and the NeXTstep codebases all ran together without issue due to several of the kernel's extensible entry-points.
On top of that, the platform had APIs that let apps talk to each other without issue.
However, little by little, Apple has backtracked on that philosophy and continues to close the system down. Quite a fascinating journey.
I'm curious if there's a Scheme interpreter somewhere as part of macos that consumes these?
PS looks like it's "sandbox-exec" that does this. Ref: https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sand...
They're great second line of defence, but large organisations tend to reject fixing RCE when you are not able to escape sandbox and so anything meaningful, so they use them as main line of defense and that makes me sad.
Unfortunately sandbox-exec isn't really documented (and supposedly deprecated?) so trying to sort this out is a bit of a headache.
I've found a number of bypasses myself, and I'm not even a security researcher, just a longtime app developer. I know where the bodies are buried, so to speak. However, I ultimately gave up looking, because Apple's security vulnerability reporting system is absolute trash; their only interest seems to be to keep you quiet for as long as possible. It's a waste of time.
My overall feeling is that macOS has become the victim of security theater, harming both users and legitimate developers with enfeedbled software and an endless stream of permissions requests—much like Apple's old parody of Windows Vista—while doing nothing to stop real attackers, who can easily bypass the security theater whenever they want.
Does escaping the sandbox just get you back to a state where there isn’t one? Or does it allow you an even more privileged state?
QubesOS design philosophy is essentially, "Everything in a booted OS image must be assumed to be able to, some way or another, access everything else in there." So you have various silos that have extremely limited communication between them (you can "push" from one VM to another, but you can never "pull" from another VM, the framebuffer is simple, etc). You're totally free to add sandboxing as useful, but it's not considered a full security boundary. Hardware virtualized VMs are, on a fairly stripped down Xen that removes a lot of attack surface in terms of legacy device emulation and other features they don't need.
Apple has done a lot of security focused improvements over the years, but modern computers and OSes are just so complicated that even they struggle to get it right regularly. And the attackers only need one mistake to achieve their goals. :(
//EDIT: As far as practicality goes, I do daily drive QubesOS as my main computer on a 2C/4T laptop with 16GB RAM - old X250. There are plenty of things it's not great at, but I'm not heavy on the "videos or video games" thing anyway. Dual booting for gaming is an option, as is a separate desktop that doesn't do anything important for gaming, but you don't need some monster machine to do practical things with Qubes. I can't have a thousand browser tabs open, but I don't do that anyway, I browse "JITless" (disable Javascript JIT as it's a ton of attack surface that's regularly exploited), and... it's a less-intense form of computer use than standard, but it also means I don't have a desire to spend all my time on a computer.
It's time to introspect and ask those critical questions: Is it really necessary to install each one of these apps, every single one of these libraries and frameworks? How can I remove dependencies from these libs and do a little core work myself? And tell the same thing to your partners, colleagues, coworkers, etc. If you find 4-5 apps doing basically the same thing (like communication or productivity tool), see if you can consolidate them into one.
IOW it's a fascinating read into security research and macOS architecture, but only pertains to a beta release of the previous major version.
(edit: I stand corrected, there's multiple vulns as TFA's very title says, and some may still be pertinent)