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?
Yep, it is the most likely the compromise to retrofit this into macOS, without breaking everything in UNIX and NeXTSTEP land that has been ported into macOS.
On Windows land you have something similar, there is the WinRT sandbox, Win32 app sandbox, secure kernel, driver guard, and a miriad of other stuff, but there are also the cracks of backwards compatibility, specially if you want a single executable able to run across all those configurations.
Mobile OSes have it easier, because of no backwards compatibility and the restrictions that are able to impose as execution model.
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! ;)
Because many of these systems aren't designed end to end to be properly secure.
The right way to do it usually fails the market due to backwards compatibility or developer pushback to adopt such features (see WinRT sandbox).
Mobile phones security has it easier, because there wasn't backwards compatibility to care about, and so far the stores gatekeeping means that developers that want to play there have to oblige anyway.
Ultimately security is incompatible with backwards compatibility. All OSes in prod today need to be rebuilt from the ground up to be secure for the next century. That means throwing out a lot of code too. It's the cost to pay.
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.
The researcher who wrote this article seems to have been able to get a lot of holes patched with credits, albeit, some of these CVEs seem years old.
I guess a company wanting as much time as possible to fix bugs is a part of the game though, are other companies really keen for you to announce found vulns ASAP? They don't control how fast people upgrade so announcing slower is always better for end users, and that must ultimately take priority over the need of researchers for publicity. Isn't this something that one has to accept when finding holes in a consumer OS as an external?
The Apple sandbox architecture seems well designed to me, usually at least. There seems to have been some breakdown in architecture or communication in this case. To the extent there are bypasses it's because we demand a lot of functionality from desktop operating systems, arguably they are the most sophisticated and complex kind of operating system out there - far more so than server platforms. Web browsers also have a lot of CVEs and it's for the same reason. We want security, but also functionality, and inevitably there's going to be a tension point in the middle where the two rub up against each other.
> You can't just add them later, on top of the legacy Mac OS and NeXTSTEP technologies.
Apple can (and has been) since it owns the whole stack, evidenced by the fact that they've been gradually hardening macOS software and hardware for two decades.
It's been gradual enough that most end users haven't noticed, but macOS developers are painfully aware of the security-related issues they have to reckon with in both major and minor updates to macOS. Example:
I think this legacy is a burden in all mainstream operating systems? There are capability-based system, but none of them have any traction.
I am not sure what the solution is. Trying to bolt on security still seems better than doing nothing at all, where an application vulnerability immediately means a compromise of the a full user account?
Responsible disclosure is immediate public disclosure with no embargoes. Embargoes are how we as users are absorbing the costs of poor security practices. If the culture was a no-warning publish culture, I would expect feature iteration and API breaks to slow down to more conservative levels as bikeshedding that stuff dwindles.
Punish fast software development iteration with public embarrassment and lost users who got hosed by the vulnerability. If Apple or whoever start dicking around and not paying bounties, release it... or better yet: sell it on the darknet; you have got to be paid for your good work, and NSA/NSO are going to need more 0-day vulnerabilities with WWIII underway!
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?
Mostly, it just gets you to a non-sandboxed state. However, I do seem to recall vaguely one issue I saw where escaping the sandbox got you a higher privileged state, I think because of a bug in the kernel logic that enforces the sandbox.
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.
I argue never dual-boot Qubes [with it installed on an internal drive] because Windows can [theoretically] read those partitions. Better to just get a separate application-specific system for gaming.
I daily drive Qubes on i7 Comet and Raptor Lakes, 64GB and 128GB RAM respectively. I run LLMs on their GTX and RTX cards (albeit slowly on the Comet Lake/GTX system). Digital crac... err gaming is the only thing I am pretty well locked out from.
For me, everything important I have could be accessed from browser(as I do full system backup) and the cookie I have in browser could allow the app to access my data. How does QubesOS help in this scenario?
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.
> If you find 4-5 apps doing basically the same thing (like communication or productivity tool), see if you can consolidate them into one.
If I could get all of my friends to switch to one communication app, that would be great, but that's only going to happen if they can get their friends to switch, and so on. Unfortunately, doing so requires them to install additional apps for communication, and no one can get everyone they talk to to switch, so they're just going to have more people on one app than another and in the end the problem gets worse.
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)
[+] [-] mike_hearn|1 year ago|reply
[+] [-] pjmlp|1 year ago|reply
On Windows land you have something similar, there is the WinRT sandbox, Win32 app sandbox, secure kernel, driver guard, and a miriad of other stuff, but there are also the cracks of backwards compatibility, specially if you want a single executable able to run across all those configurations.
Mobile OSes have it easier, because of no backwards compatibility and the restrictions that are able to impose as execution model.
[+] [-] fudged71|1 year ago|reply
[deleted]
[+] [-] pram|1 year ago|reply
[+] [-] doctorpangloss|1 year ago|reply
https://news.ycombinator.com/item?id=37655477
There's no security model for desktops that works well.
Like another commenter said iOS has no legacy cruft and could deliver the security model that made sense.
On the other hand, when Telegram asks you to share all your contacts and images with it, people do.
[+] [-] boesboes|1 year ago|reply
[+] [-] pjmlp|1 year ago|reply
The right way to do it usually fails the market due to backwards compatibility or developer pushback to adopt such features (see WinRT sandbox).
Mobile phones security has it easier, because there wasn't backwards compatibility to care about, and so far the stores gatekeeping means that developers that want to play there have to oblige anyway.
[+] [-] gxt|1 year ago|reply
[+] [-] jarjoura|1 year ago|reply
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.
[+] [-] smw|1 year ago|reply
[+] [-] imglorp|1 year ago|reply
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...
[+] [-] mdaniel|1 year ago|reply
[+] [-] HoyaSaxa|1 year ago|reply
[+] [-] Szpadel|1 year ago|reply
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.
[+] [-] n8henrie|1 year ago|reply
Unfortunately sandbox-exec isn't really documented (and supposedly deprecated?) so trying to sort this out is a bit of a headache.
[+] [-] lapcat|1 year ago|reply
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.
[+] [-] mike_hearn|1 year ago|reply
I guess a company wanting as much time as possible to fix bugs is a part of the game though, are other companies really keen for you to announce found vulns ASAP? They don't control how fast people upgrade so announcing slower is always better for end users, and that must ultimately take priority over the need of researchers for publicity. Isn't this something that one has to accept when finding holes in a consumer OS as an external?
The Apple sandbox architecture seems well designed to me, usually at least. There seems to have been some breakdown in architecture or communication in this case. To the extent there are bypasses it's because we demand a lot of functionality from desktop operating systems, arguably they are the most sophisticated and complex kind of operating system out there - far more so than server platforms. Web browsers also have a lot of CVEs and it's for the same reason. We want security, but also functionality, and inevitably there's going to be a tension point in the middle where the two rub up against each other.
[+] [-] CharlesW|1 year ago|reply
Apple can (and has been) since it owns the whole stack, evidenced by the fact that they've been gradually hardening macOS software and hardware for two decades.
It's been gradual enough that most end users haven't noticed, but macOS developers are painfully aware of the security-related issues they have to reckon with in both major and minor updates to macOS. Example:
[+] [-] microtonal|1 year ago|reply
I am not sure what the solution is. Trying to bolt on security still seems better than doing nothing at all, where an application vulnerability immediately means a compromise of the a full user account?
[+] [-] CraigJPerry|1 year ago|reply
SELinux managed it, what's fundamentally stopping MacOS?
[+] [-] cyberax|1 year ago|reply
[+] [-] rustcleaner|1 year ago|reply
Punish fast software development iteration with public embarrassment and lost users who got hosed by the vulnerability. If Apple or whoever start dicking around and not paying bounties, release it... or better yet: sell it on the darknet; you have got to be paid for your good work, and NSA/NSO are going to need more 0-day vulnerabilities with WWIII underway!
[+] [-] RoxaneFischer1|1 year ago|reply
[+] [-] StrangeDoctor|1 year ago|reply
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?
[+] [-] lapcat|1 year ago|reply
[+] [-] w10-1|1 year ago|reply
[+] [-] Syonyk|1 year ago|reply
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.
[+] [-] rustcleaner|1 year ago|reply
I daily drive Qubes on i7 Comet and Raptor Lakes, 64GB and 128GB RAM respectively. I run LLMs on their GTX and RTX cards (albeit slowly on the Comet Lake/GTX system). Digital crac... err gaming is the only thing I am pretty well locked out from.
[+] [-] YetAnotherNick|1 year ago|reply
[+] [-] normie3000|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] pyeri|1 year ago|reply
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.
[+] [-] danudey|1 year ago|reply
If I could get all of my friends to switch to one communication app, that would be great, but that's only going to happen if they can get their friends to switch, and so on. Unfortunately, doing so requires them to install additional apps for communication, and no one can get everyone they talk to to switch, so they're just going to have more people on one app than another and in the end the problem gets worse.
[+] [-] lmz|1 year ago|reply
I thought this was called a monoculture and was a bad thing when e.g. Crowdstrike was the one app chosen?
[+] [-] rustcleaner|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] henriy|1 year ago|reply
[deleted]
[+] [-] nielsbot|1 year ago|reply
[deleted]
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] wannacboatmovie|1 year ago|reply
[+] [-] saagarjha|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] chuckadams|1 year ago|reply
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)
[+] [-] jmmv|1 year ago|reply
… clarifying in case someone else reads it the same way.