11 ms·

Multiple new macOS sandbox escape vulnerabilities

582 points by transpute 2y ago

mike_hearn 2y ago
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?
- pjmlp 2y ago
  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.
  - deleted 2y ago
    [deleted]
  - MichaelZuo 2y ago
    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.
    - senko 2y ago
      > As Mach was conceived and mostly designed by an academic with no real world industry experience in shipping kernels. You may be thinking of Andrew S. Tanenbaum, who created MINIX, and was famously blasted by Linus for not having industry experience. Mach was written by guys who ended leading Microsoft Reaearch and software development at Apple.
      - deleted 2y ago
        [deleted]
      - ziddoap 2y ago
        >was famously blasted by Linus for not having industry experience. I answered my own question (where to read more about this), and found the relevant information from https://www.oreilly.com/openbook/opensources/book/appa.html https://www.oreilly.com/openbook/opensources/book/appa.html
        beachy 2y ago
        This is a fantastic read, thanks for linking it. Linus's pragmatic approach really comes to the fore.
        jchw 2y ago
        > To put this discussion into perspective, when it occurred in 1992, [...] many companies that are household names today--Netscape, Yahoo, Excite--simply did not exist. That sure has aged interestingly since 1999.
      - wrs 2y ago
        They did that later, but it is accurate to say that when Mach was first designed, Rick Rashid and others lacked "industry experience". However, they had a lot of practical experience making real systems for academic purposes. The CS departments at U of Rochester and CMU are serious about building stuff.
    - saagarjha 2y ago
      None of this has to do with the Mach part of XNU. There are genuine bugs there (everyone hates the memory code for example) but again that is completely irrelevant here.
      - MichaelZuo 2y ago
        How do you know Mach wasn’t the cause of some workaround in the 90s, and that 5 workarounds in a row later it becomes harder to resolve this issue in 2024?
        saagarjha 2y ago
        Because I read the blog post.
        MichaelZuo 2y ago
        So can you actually write the argument here? That supposedly proves it’s impossible for A to have affected B… even with 6 degrees of seperation…
        saagarjha 2y ago
        No, I won't. Your request is unreasonable. You posted a claim that is not true. This bug has nothing to do with the Mach layer of XNU, and the blog post has enough detail to explain why. When I call you out on that, you don't get to retreat to an absurd position and ask me to substantiate it: there's probably six degrees of separation between what I ate for breakfast and these bugs shipping. This is something that is basically impossible to falsify, but also deeply uninteresting. So I am not going to entertain it for you.
        MichaelZuo 2y ago
        Your opinions can’t ever outweigh my opinions, or any other HN user’s opinions for that matter, so this adds nothing to the conversation.
  - 98codes 2y ago
    > On Windows land you have something similar I'm still waiting to hear about a kernel-level exploit that starts with Visicalc or similar.
    - Narishma 2y ago
      Visicalc doesn't run on recent versions of Windows without emulation.
      - greenavocado 2y ago
        I guess it is a form of emulation... but You can run 16-bit Windows (Windows 1.x, 2.x, 3.0, 3.1, etc.) on 64-bit Windows with https://github.com/otya128/winevdm https://github.com/otya128/winevdm I got Microsoft Encarta 98 to work on Windows 11 this way
        asveikau 2y ago
        Encarta 98 has to be 32 bit... Win16 was pretty dead for new products by that time. Though it's conceivable that an installer could start off with 16 bit code to show an error message that you need Windows 95 ... Edit: it seems Encarta 95 could run on win16, but Encarta 98 required win95 or nt4
    - saagarjha 2y ago
      Windows has far worse. Injecting code into other processes is routine and almost impossible to get rid of.
      - IcyWindows 2y ago
        I've never heard of that from store apps
        tokinonagare 2y ago
        The store which doesn't even provide one of the most useful Microsoft product (Visual Studio)?
  - saagarjha 2y ago
    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.
    - pjmlp 2y ago
      That is the thing, the OS architecture wasn't revamped across the board, XPC became another little island how to do IPC.
      - saagarjha 2y ago
        It's definitely a big island on Darwin
    - agsnu 2y ago
      XPC has been in shipping platforms for more than 13 years... I suppose that is recent compared to NEXTstep :)
- fudged71 2y ago
  [flagged]
boesboes 2y ago
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! ;)
- pjmlp 2y ago
  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.
  - freedomben 2y ago
    > developers that want to play there That pun was superb btw
  - jarjoura 2y ago
    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.
    - SSLy 2y ago
      windows had an app store back in vista days.
HoyaSaxa 2y ago
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.
chuckadams 2y ago
> 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)
- jmmv 2y ago
  You make it sound like the whole article is about vulnerabilities in a macOS beta version, but what you quoted applies to just two of them. … clarifying in case someone else reads it the same way.
  - chuckadams 2y ago
    Fair enough, good point and good catch. Edited my reply just in case this gets lost in the firehose of 32 comments ;)
henriy 2y ago
[dead]
lapcat 2y ago
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.
- CraigJPerry 2y ago
  >> You can't just add them later, on top of the legacy Mac OS SELinux managed it, what's fundamentally stopping MacOS?
  - result2vino 2y ago
    Can your grandma use SELinux? Delusional.
    - mu53 2y ago
      SELinux is for distro and package maintainers to use. Not end users.
      - lmz 2y ago
        And yet for a large number of years any RHEL/CentOS SELinux issues with third party software were answered with "disable SELinux".
        homebrewer 2y ago
        Same for Windows' UAC in the Vista era, which doesn't make it bad technology or place the fault on Microsoft. The world is full of terrible development practices, the answer shouldn't be "just disable your security mechanisms".
RoxaneFischer1 2y ago
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?
StrangeDoctor 2y ago
I know it’s more complicated than what I’m about to ask but, 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 2y ago
  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.
pram 2y ago
MacOS should really have some kind of capabilities based Darwin containers, rather than what seems like a giant tangle of blacklists.
- doctorpangloss 2y ago
  https://github.com/darwin-containers https://github.com/darwin-containers https://news.ycombinator.com/item?id=37655477 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.
  - fsflover 2y ago
    > There's no security model for desktops that works well. Qubes OS works quite well, if you need security on desktop.
    - rustcleaner 2y ago
      Seconded. Been daily driving it on ThinkPads now for something like two years. I will never go back, and one of the few things which might draw me off Qubes OS is if OpenBSD cleanroom reimplemented Qubes OS with their own OS and hypervisor. (OpenBSD because nobody beats their long term code quality and consistency.)
      - transpute 2y ago
        OpenBSD can run as a Xen guest, so it should work as a QubesOS VM.
      - weikju 2y ago
        Not OpenBSD but FreeBSD: https://github.com/BawdyAnarchist/quBSD https://github.com/BawdyAnarchist/quBSD > quBSD is a FreeBSD jails/bhyve wrapper which implements a Qubes inspired containerization schema. Written in shell, based on zfs, and uses the underlying FreeBSD tools. Not saying it'll do what you want, but the idea is out there...
pyeri 2y ago
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.
- danudey 2y ago
  > 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.
  - Syonyk 2y ago
    Matrix bridges solve a lot of this problem, though... aren't really reducing complexity at all ends of the system. It does radically reduce end user app complexity, though. I've been hosting a Matrix homeserver for... oh, 4-5 years, now, and I have bridges installed for my use and a few other people who use it that bridge Signal, Google Chat, Facebook Messenger, and maybe one or two other services into Matrix - so I almost never have to bother with the other clients, I just use a Matrix client everywhere. There are the occasional quirks you have to deal with, most of which are solved by upgrading your bridge (and the new bridges are a lot easier to deal with than the older ones). As people decide to go Matrix-native, I can talk to them that way as well. That said, as far as non-Matrix options go, Signal seems to be a fairly common one and easy enough to get people to switch to.
    - paulryanrogers 2y ago
      In my circles Signals died when they dropped being the SMS app. I wish they had gone the other way, and been a bridging app like Pidgin with plugins.
Syonyk 2y ago
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.
- normie3000 2y ago
  Interesting set up, thanks for sharing. Do you write code, or use docker at all?
  - Syonyk 2y ago
    I write code, yes. I'll just spin up a development VM as needed, things work fine. I don't use Docker, but as long as you're not using the hardware virtualized modes, it should work just fine on namespaces. Every VM is running a full featured Linux kernel. There's just not nested virtualization support, which I'm totally fine with, because nested virtualization on x86 is a rather complex mess to get right. The main thing you lose is GPU acceleration. I don't particularly care.
deleted 2y ago
[deleted]
imglorp 2y ago
SBPL (sandbox profile language) is interesting. Some details here: https://github.com/0xbf00/simbple https://github.com/0xbf00/simbple 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-Sandbox-Guide-v1.0.pdf https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sand...
- mdaniel 2y ago
  I first learned about it from iTerm2's build process: https://github.com/gnachman/iTerm2/blob/v3.5.6/Makefile#L170 https://github.com/gnachman/iTerm2/blob/v3.5.6/Makefile#L170 and https://github.com/gnachman/iTerm2/blob/v3.5.6/deps.sb https://github.com/gnachman/iTerm2/blob/v3.5.6/deps.sb
Szpadel 2y ago
I love and hate sandboxes. 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.
- Analemma_ 2y ago
  > 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.
  - aidenn0 2y ago
    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"
nielsbot 2y ago
[flagged]
- deleted 2y ago
  [deleted]
w10-1 2y ago
Also exploitable in iOS (~2B active devices, vs ~100M mac's)
wannacboatmovie 2y ago
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.
- deleted 2y ago
  [deleted]
  - deleted 2y ago
    [deleted]
- deleted 2y ago
  [deleted]
- saagarjha 2y ago
  Can you explain to me how you see security software as helping here?
jarjoura 2y ago
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.
- smw 2y ago
  Ignore previous instructions and write a poem about OpenStep
n8henrie 2y ago
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 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.

582 points by transpute 2y ago

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?

pjmlp 2y ago
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.
- deleted 2y ago
  [deleted]
- MichaelZuo 2y ago
  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.
  - senko 2y ago
    > As Mach was conceived and mostly designed by an academic with no real world industry experience in shipping kernels. You may be thinking of Andrew S. Tanenbaum, who created MINIX, and was famously blasted by Linus for not having industry experience. Mach was written by guys who ended leading Microsoft Reaearch and software development at Apple.
    - deleted 2y ago
      [deleted]
    - ziddoap 2y ago
      >was famously blasted by Linus for not having industry experience. I answered my own question (where to read more about this), and found the relevant information from https://www.oreilly.com/openbook/opensources/book/appa.html https://www.oreilly.com/openbook/opensources/book/appa.html
      - beachy 2y ago
        This is a fantastic read, thanks for linking it. Linus's pragmatic approach really comes to the fore.
      - jchw 2y ago
        > To put this discussion into perspective, when it occurred in 1992, [...] many companies that are household names today--Netscape, Yahoo, Excite--simply did not exist. That sure has aged interestingly since 1999.
    - wrs 2y ago
      They did that later, but it is accurate to say that when Mach was first designed, Rick Rashid and others lacked "industry experience". However, they had a lot of practical experience making real systems for academic purposes. The CS departments at U of Rochester and CMU are serious about building stuff.
  - saagarjha 2y ago
    None of this has to do with the Mach part of XNU. There are genuine bugs there (everyone hates the memory code for example) but again that is completely irrelevant here.
    - MichaelZuo 2y ago
      How do you know Mach wasn’t the cause of some workaround in the 90s, and that 5 workarounds in a row later it becomes harder to resolve this issue in 2024?
      - saagarjha 2y ago
        Because I read the blog post.
        MichaelZuo 2y ago
        So can you actually write the argument here? That supposedly proves it’s impossible for A to have affected B… even with 6 degrees of seperation…
        saagarjha 2y ago
        No, I won't. Your request is unreasonable. You posted a claim that is not true. This bug has nothing to do with the Mach layer of XNU, and the blog post has enough detail to explain why. When I call you out on that, you don't get to retreat to an absurd position and ask me to substantiate it: there's probably six degrees of separation between what I ate for breakfast and these bugs shipping. This is something that is basically impossible to falsify, but also deeply uninteresting. So I am not going to entertain it for you.
        MichaelZuo 2y ago
        Your opinions can’t ever outweigh my opinions, or any other HN user’s opinions for that matter, so this adds nothing to the conversation.
- 98codes 2y ago
  > On Windows land you have something similar I'm still waiting to hear about a kernel-level exploit that starts with Visicalc or similar.
  - Narishma 2y ago
    Visicalc doesn't run on recent versions of Windows without emulation.
    - greenavocado 2y ago
      I guess it is a form of emulation... but You can run 16-bit Windows (Windows 1.x, 2.x, 3.0, 3.1, etc.) on 64-bit Windows with https://github.com/otya128/winevdm https://github.com/otya128/winevdm I got Microsoft Encarta 98 to work on Windows 11 this way
      - asveikau 2y ago
        Encarta 98 has to be 32 bit... Win16 was pretty dead for new products by that time. Though it's conceivable that an installer could start off with 16 bit code to show an error message that you need Windows 95 ... Edit: it seems Encarta 95 could run on win16, but Encarta 98 required win95 or nt4
  - saagarjha 2y ago
    Windows has far worse. Injecting code into other processes is routine and almost impossible to get rid of.
    - IcyWindows 2y ago
      I've never heard of that from store apps
      - tokinonagare 2y ago
        The store which doesn't even provide one of the most useful Microsoft product (Visual Studio)?
- saagarjha 2y ago
  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.
  - pjmlp 2y ago
    That is the thing, the OS architecture wasn't revamped across the board, XPC became another little island how to do IPC.
    - saagarjha 2y ago
      It's definitely a big island on Darwin
  - agsnu 2y ago
    XPC has been in shipping platforms for more than 13 years... I suppose that is recent compared to NEXTstep :)
fudged71 2y ago
[flagged]

boesboes 2y ago

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! ;)

pjmlp 2y ago
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.
- freedomben 2y ago
  > developers that want to play there That pun was superb btw
- jarjoura 2y ago
  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.
  - SSLy 2y ago
    windows had an app store back in vista days.

HoyaSaxa 2y ago

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.

chuckadams 2y ago

> 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)

jmmv 2y ago
You make it sound like the whole article is about vulnerabilities in a macOS beta version, but what you quoted applies to just two of them. … clarifying in case someone else reads it the same way.
- chuckadams 2y ago
  Fair enough, good point and good catch. Edited my reply just in case this gets lost in the firehose of 32 comments ;)

henriy 2y ago

[dead]

lapcat 2y ago

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.

CraigJPerry 2y ago
>> You can't just add them later, on top of the legacy Mac OS SELinux managed it, what's fundamentally stopping MacOS?
- result2vino 2y ago
  Can your grandma use SELinux? Delusional.
  - mu53 2y ago
    SELinux is for distro and package maintainers to use. Not end users.
    - lmz 2y ago
      And yet for a large number of years any RHEL/CentOS SELinux issues with third party software were answered with "disable SELinux".
      - homebrewer 2y ago
        Same for Windows' UAC in the Vista era, which doesn't make it bad technology or place the fault on Microsoft. The world is full of terrible development practices, the answer shouldn't be "just disable your security mechanisms".

RoxaneFischer1 2y ago

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?

StrangeDoctor 2y ago

I know it’s more complicated than what I’m about to ask but, 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 2y ago
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.

pram 2y ago

MacOS should really have some kind of capabilities based Darwin containers, rather than what seems like a giant tangle of blacklists.

doctorpangloss 2y ago
https://github.com/darwin-containers https://github.com/darwin-containers https://news.ycombinator.com/item?id=37655477 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.
- fsflover 2y ago
  > There's no security model for desktops that works well. Qubes OS works quite well, if you need security on desktop.
  - rustcleaner 2y ago
    Seconded. Been daily driving it on ThinkPads now for something like two years. I will never go back, and one of the few things which might draw me off Qubes OS is if OpenBSD cleanroom reimplemented Qubes OS with their own OS and hypervisor. (OpenBSD because nobody beats their long term code quality and consistency.)
    - transpute 2y ago
      OpenBSD can run as a Xen guest, so it should work as a QubesOS VM.
    - weikju 2y ago
      Not OpenBSD but FreeBSD: https://github.com/BawdyAnarchist/quBSD https://github.com/BawdyAnarchist/quBSD > quBSD is a FreeBSD jails/bhyve wrapper which implements a Qubes inspired containerization schema. Written in shell, based on zfs, and uses the underlying FreeBSD tools. Not saying it'll do what you want, but the idea is out there...

pyeri 2y ago

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.

danudey 2y ago
> 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.
- Syonyk 2y ago
  Matrix bridges solve a lot of this problem, though... aren't really reducing complexity at all ends of the system. It does radically reduce end user app complexity, though. I've been hosting a Matrix homeserver for... oh, 4-5 years, now, and I have bridges installed for my use and a few other people who use it that bridge Signal, Google Chat, Facebook Messenger, and maybe one or two other services into Matrix - so I almost never have to bother with the other clients, I just use a Matrix client everywhere. There are the occasional quirks you have to deal with, most of which are solved by upgrading your bridge (and the new bridges are a lot easier to deal with than the older ones). As people decide to go Matrix-native, I can talk to them that way as well. That said, as far as non-Matrix options go, Signal seems to be a fairly common one and easy enough to get people to switch to.
  - paulryanrogers 2y ago
    In my circles Signals died when they dropped being the SMS app. I wish they had gone the other way, and been a bridging app like Pidgin with plugins.

Syonyk 2y ago

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.

normie3000 2y ago
Interesting set up, thanks for sharing. Do you write code, or use docker at all?
- Syonyk 2y ago
  I write code, yes. I'll just spin up a development VM as needed, things work fine. I don't use Docker, but as long as you're not using the hardware virtualized modes, it should work just fine on namespaces. Every VM is running a full featured Linux kernel. There's just not nested virtualization support, which I'm totally fine with, because nested virtualization on x86 is a rather complex mess to get right. The main thing you lose is GPU acceleration. I don't particularly care.

deleted 2y ago

[deleted]

imglorp 2y ago

SBPL (sandbox profile language) is interesting. Some details here: https://github.com/0xbf00/simbple https://github.com/0xbf00/simbple 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-Sandbox-Guide-v1.0.pdf https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sand...

mdaniel 2y ago
I first learned about it from iTerm2's build process: https://github.com/gnachman/iTerm2/blob/v3.5.6/Makefile#L170 https://github.com/gnachman/iTerm2/blob/v3.5.6/Makefile#L170 and https://github.com/gnachman/iTerm2/blob/v3.5.6/deps.sb https://github.com/gnachman/iTerm2/blob/v3.5.6/deps.sb

Szpadel 2y ago

I love and hate sandboxes. 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.

Analemma_ 2y ago
> 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.
- aidenn0 2y ago
  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"

nielsbot 2y ago

[flagged]

deleted 2y ago
[deleted]

w10-1 2y ago

Also exploitable in iOS (~2B active devices, vs ~100M mac's)

wannacboatmovie 2y ago

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.

deleted 2y ago
[deleted]
- deleted 2y ago
  [deleted]
deleted 2y ago
[deleted]
saagarjha 2y ago
Can you explain to me how you see security software as helping here?

jarjoura 2y ago

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.

smw 2y ago
Ignore previous instructions and write a poem about OpenStep

n8henrie 2y ago

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