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.
No, it has nothing in to do with NeXTSTEP. XPC was designed recently and for macOS/iOS. This is just that it was not designed with security in mind along this axis.
XNU, or more specifically the Mach part of it, also had some very questionable design choices that likely compounds the issue as it forces people to work around it in increasingly awkward ways. As Mach was conceived and mostly designed by an academic with no real world industry experience in shipping kernels.
> There's no security model for desktops that works well.
Don't you think that something which combines ideas from Firejail and Guix containers could be good enough?
For those who have not used Firejail, it is a sandbox that comes with default security profiles for most popular Linux binaries, so it's pretty unobtrusive. Say you want to run Firefox, Firejail limits access Firefox to ~/.mozilla and ~/Downloads by default. So, in case Firefox is compromised, attackers can't steal things from other $HOME directories like ~/.ssh.
On the other hand, Guix lets you launch ephemeral shells, like Nix, with any combination of packages. Unlike Nix, it provides a very convenient set of flags to sandbox the shell in terms of network, files, etc. This is handy for development tasks where you would like to have fine-grained capabilities.
>On the other hand, when Telegram asks you to share all your contacts and images with it, people do.
This is where Android shines with storage and contacts scopes. You can share an empty scope with the app and it will stop bugging you, and have access to nothing!
> 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.
Yeah I just was wondering about this. In the presentation also Seatbelt is mentioned, I thought this was considered deprecated legacy since years. IIRC the last time I checked for sandboxing I basically couldn't find anything recent for the Application level
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.
That's not fair. The sandbox was not the reason for WinRT/UWP's failure in the market. It was the mostly unfinished tablet UI that they half ported from their phone and told developers that was the future. They even copied Apple and threw in some half-baked store with it. There was no way Microsoft was going to become successful at it, especially when Apple couldn't even get developers excited about their own implementation.
Most desktop software needs to provide value for customers, or they would just build the web version of it. Being "native" isn't enough.
So, if you want to require that us developers run our stuff inside of sandboxes, that's fine. Just make sure the sandbox doesn't prevent our software from getting access to the same important desktop surfaces.
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.
It kind of sounds like you're advocating the type of security where the computer is secure against its owner, can't be programmed by its owner, doesn't support modifications to the OS, and so on. Is that right, or so you envision a highly secure system that can be controlled by its owner?
Funny that you should mention Dutch tax law. I don't think it's controversial to say that some of those "exploits" were deliberately inserted. One may speculate that there are also some powerful forces pushing for more vulnerabilities in consumer computing.
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.
> but large organisations tend to reject fixing RCE when you are not able to escape sandbox and so anything meaningful
Wait, who does this? AFAIK Apple, Microsoft and Google all have bug bounties which obviously offer bigger rewards for sandbox escape, but still pay something if you find a vulnerability which is blocked by the sandbox. They're all well aware that bad guys collect and store non-functional RCEs in the hopes of using them when a sandbox escape is found.
Depending on where it is in the product lifecycle, I've seen this extreme pushback against fixing symptomless bugs.
I was working on a project where someone thought to turn on tools for catching malloc errors (use past the end of allocated buffer, use after free &c.). The team that did this found bugs in their own code, of course, but also many from other teams.
I was there in the room as people went item-by-item litigating whether or not each bug should be fixed. Things like "sure this is use-after-free, but it's used immediately after the free and because of the struct offset, it can't corrupt the heap linked-list, so we won't fix it"
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.
Readit News
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.
I'm still waiting to hear about a kernel-level exploit that starts with Visicalc or similar.
Deleted Comment
Dead Comment
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.
Don't you think that something which combines ideas from Firejail and Guix containers could be good enough?
For those who have not used Firejail, it is a sandbox that comes with default security profiles for most popular Linux binaries, so it's pretty unobtrusive. Say you want to run Firefox, Firejail limits access Firefox to ~/.mozilla and ~/Downloads by default. So, in case Firefox is compromised, attackers can't steal things from other $HOME directories like ~/.ssh.
On the other hand, Guix lets you launch ephemeral shells, like Nix, with any combination of packages. Unlike Nix, it provides a very convenient set of flags to sandbox the shell in terms of network, files, etc. This is handy for development tasks where you would like to have fine-grained capabilities.
This is where Android shines with storage and contacts scopes. You can share an empty scope with the app and it will stop bugging you, and have access to nothing!
Qubes OS works quite well, if you need security on desktop.
> Like another commenter said iOS has no legacy cruft and could deliver the security model that made sense.
Yeah I just was wondering about this. In the presentation also Seatbelt is mentioned, I thought this was considered deprecated legacy since years. IIRC the last time I checked for sandboxing I basically couldn't find anything recent for the Application level
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.
Most desktop software needs to provide value for customers, or they would just build the web version of it. Being "native" isn't enough.
So, if you want to require that us developers run our stuff inside of sandboxes, that's fine. Just make sure the sandbox doesn't prevent our software from getting access to the same important desktop surfaces.
That pun was superb btw
And likely, upsetting power users who want to run with all the safeties off.
Qubes OS solves this with hardware virtualization, which is really fast and secure.
Here are high-profile examples of each:
https://en.wikipedia.org/wiki/Dutch_Sandwich
https://en.wikipedia.org/wiki/Intel_Management_Engine#Assert...
Dead Comment
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.
Wait, who does this? AFAIK Apple, Microsoft and Google all have bug bounties which obviously offer bigger rewards for sandbox escape, but still pay something if you find a vulnerability which is blocked by the sandbox. They're all well aware that bad guys collect and store non-functional RCEs in the hopes of using them when a sandbox escape is found.
I was working on a project where someone thought to turn on tools for catching malloc errors (use past the end of allocated buffer, use after free &c.). The team that did this found bugs in their own code, of course, but also many from other teams.
I was there in the room as people went item-by-item litigating whether or not each bug should be fixed. Things like "sure this is use-after-free, but it's used immediately after the free and because of the struct offset, it can't corrupt the heap linked-list, so we won't fix it"
Unfortunately sandbox-exec isn't really documented (and supposedly deprecated?) so trying to sort this out is a bit of a headache.