15 ms·

Breaking all macOS security layers with a single vulnerability

606 points by afrcnc 4y ago

blinkingled 4y ago
>Changing a security model that has been used for decades to a more restrictive model is difficult, especially in something as complicated as macOS. Attaching debuggers is just one example, there are many similar techniques that could be used to inject code into a different process. Apple has squashed many of these techniques, but many other ones are likely still undiscovered. > Aside from Apple’s own code, these vulnerabilities could also occur in third-party software. It’s quite common to find a process injection vulnerability in a specific application, which means that the permissions (TCC permissions and entitlements) of that application are up for grabs for all other processes. Getting those fixed is a difficult process, because many third-party developers are not familiar with this new security model. Reporting these vulnerabilities often requires fully explaining this new model! Especially Electron applications are infamous for being easy to inject into, as it is possible to replace their JavaScript files without invalidating the code signature. It makes me sad that we are likely not going to see any new fundamental design rethink for security's sake in mainstream operating systems. It is cost prohibitive at this point to do something that gets security right for the world of 2022 and yet not break all the apps which would never be rewritten! Mobile OSes were a good break off point as far as security goes but that came with a lot of functionality sacrifice. Although something like QubesOS can theoretically dream of being semi-mainstream with support from hardware and OSS OS vendors like RH/Suse/Canonical or even Microsoft.
- olliej 4y ago
  Fuchsia does a pure capability model, and resources, even as basic as the file system are provided through handles - and your file system handle is a handle to what would be a directory elsewhere, but that is the entire file system so it’s not a matter of finding a traversal exploit. In principle you could do something similar with the Mac/iOS sandbox by starting a process with a compute only sandbox, and then provide it with specific sandbox entitlements (from the parent) which includes specific file systems, however they still in principle can see a full version of the fs. And yeah, any OS that isn’t completely new is burdened with support for old apps, but then iOS which used its newness to have a stronger base security model is constantly beaten up for that model.
  - blinkingled 4y ago
    Ah, I forgot about Fuchsia - https://arxiv.org/pdf/2108.04183.pdf https://arxiv.org/pdf/2108.04183.pdf seems to do a good job of explaining the security architecture without complicating things. With Google's backing (if they don't lose interest that is) and the potential to take over Nest/Chromebook/Android devices it might go farther than most new OS experiments.
- eru 4y ago
  > It is cost prohibitive at this point to do something that gets security right for the world of 2022 and yet not break all the apps which would never be rewritten! You could quarantine your old applications to their own individual VMs, while newer programs can make use of your shiny new security features?
  - blinkingled 4y ago
    Sort of like Fuchsia/QubesOS combo, interesting.
    - eru 4y ago
      Maybe, I don't know these. I was just pointing out that we can have both progress and backwards compatibility. Just like we can still play old games via dosbox, but that doesn't mean we have to run DOS as our main OS.
  - KerrAvon 4y ago
    Harder than it sounds, though. You still have to be able to communicate with other processes to present the user with a usable UI, so the isolation is never really complete. There are lots of variations on this theme and they all have to compromise in some way.
    - hn_throwaway_99 4y ago
      True, but Apple still did it to allow Classic Mac apps to run on OS X when the initial version of OS X was released.
    - eru 4y ago
      Oh, it's definitely no walk in the park. But more realistic than rewriting all old programs in one go.
    - samus 4y ago
      It's perfectly possible to have that with something like the X window system. The irony is that this protocol gives applications way too many capabilities. But Wayland is a chance to fix that for good and finally have proper compartmentalisation in the GUI.
- Syonyk 4y ago
  > Although something like QubesOS can theoretically dream of being semi-mainstream with support from hardware and OSS OS vendors like RH/Suse/Canonical or even Microsoft. I'm trying to encourage as many people as I can to run it, or at least play with it for some while to gain familiarity with it. Properly applied, I think it does add quite a bit of useful practical security... though it's not going to automatically solve all problems. I like the silos of compromise, at least, and you can do high risk things (like "anything web") in disposable VMs that reset on VM power cycle. My only major concern with Qubes is that I've not decided if it's weird and niche enough to be mostly left alone by the 0day markets, or if it's a super high priority, high value target to attack because of the type of people who are likely to use it. I'd like to see an ARM port of it, because Xen on ARM is quite a bit simpler than Xen on x86, but the hardware to run that doesn't quite exist yet. Maybe with the RK3588... The fundamental problem here is that software developers (and I'm guilty here too, as much as anyone in that industry) tend to view complexity as a one way ratchet function - add features. Add features. Add features. Add knobs. And when it comes crashing down around your ears, "add security" (in the form of sandboxes, or process isolation, or... https://xkcd.com/2044/ https://xkcd.com/2044/ applies here). And then it turns out that "adding complexity to solve problems created by complexity" isn't a strategy with a great long term success rate. I'm slightly encouraged by Apple admitting, as clearly as they ever admit anything, that this strategy isn't working - with their Lockdown mode, that's "only for people with the most extreme threats, blah blah blah," and I'd expect anyone in the security or software industry to turn that on basically as soon as they get iOS 16 and not look back. Or install the beta to give that option.
  - dmz73 4y ago
    I have tried the QubesOS and boy does it bring back memories of Windows being called Pentium to 286 converter. It is slow as molasses on hardware where even Windows 10 and Gnome are both fast and to make it usable you have to keep relaxing the security to the point where it is probably less secure than regular OS. And don't even bother if you have to use scaling other than 100%, sure you can scale the DOM0 but the rest of the VMs are not scaled and there is no documentation on how to do it. What we need are simple sandboxes that isolate GUI applications into chroot environment and keep them away from other applications and documents.
- userbinator 4y ago
  It makes me sad that we are likely not going to see any new fundamental design rethink for security's sake in mainstream operating systems. Contrarily, that makes me happy because if that happens we are really going to lose what little computing freedom we have left, as it will only make the walled garden silos even stronger.
  - matheusmoreira 4y ago
    Yeah. The problem with all these security innovations is they allow corporations to seize control. The ability to debug and intercept is also the ability to reverse engineer and override. We need secure software that empowers us, not some secure walled garden.
  - eastbound 4y ago
    It’s hard to sign off SOC2 compliance when you know that npm and maven packages can be introduced by any mistake on your team and contain an “Upload all files from HDD to a rogue server” script. I’d need to operate administrative files (customer records, contracts, accounting) on a separate machine from dev… App sandboxing is… the way it will go, for insurance reasons.
    - wila 4y ago
      > I’d need to operate administrative files (customer records, contracts, accounting) on a separate machine from dev You're saying that like it is a bad thing? A developer probably shouldn't have access to all that live data anyways.
      - eastbound 4y ago
        As a founder-developer of a company of 3, would you expect me to have 2 computers, for the security of customer data? It’s an interesting idea, I’m just asking.
        skrtskrt 4y ago
        For such a small company I would probably expect that data like that would probably just live in a cloud service like GSuite that’s already SOC2 compliant, then if you’re running software integrations against that data, you’re spinning up isolated SOC2-compliant cloud servers to do so. Unfortunately unless you get ridiculously creative and put in a bunch of extra time instead of cloud service spend, SOC2 compliance is gonna be expensive
- solarkraft 4y ago
  > Mobile OSes were a good break off point as far as security goes but that came with a lot of functionality sacrifice. I have a tiny bit of hope that they'll eventually be able to replace desktop OSes through virtualization. It's actually what I long thought Apple would do with iPad OS (why else put in an M1?).
- mhoad 4y ago
  Google’s upcoming Fuchsia OS has an entirely new security model that looks really solid. I imagine it’s still a few years away however from any kind of desktop usage.
- londons_explore 4y ago
  I think a lot of users would be fine with apps being fully silo'ed from eachother with the exception of being able to copy and paste between them, and have 'File Open' dialog boxes able to access files from anywhere. Every other kind of interaction between seperate applications can be blocked without breaking much functionality. And you can limit breakage further by running all 'legacy' applications in the same silo, and only running new applications disconnected from eachother.
  - noduerme 4y ago
    Literally any other kind of interaction between applications feels like the apps are spying on me. I don't even want one to suggest which app I should open for a doc. Mac OS has taken security in a strange direction where you can't change the suffix of a file without exposing possible vulnerabilities by apps automatically opening it - and the backstop is supposed to be validating all applications through your "apple account" (whatever that is?). (although in some sense the suffix and permissions flaws have been around since System 7).
- deleted 4y ago
  [deleted]
- still_grokking 4y ago
  Well, GNU Hurd 2 is going to be released real soon now. It will fix all the issues with current OS architectures. And than, at some point Google's Fuchsia will also surface in mainstream likely. Both systems will bring capability-security. (You know, almost like seL4, only less secure). A technology that wasn't used until now, even it's available for almost 50 years, and would solve almost all security problems of computers. We could have had that in fact directly supported by hardware almost four decades ago… But the market didn't like that. The problem is that there is and won't be any progress in computer technology. It's like that since at least one hundred years. We're buried in the von Neumann local "optimum" since than… As long as this does not change we're doomed to have crappy, inefficient, and insecure computers. The invisible hand will just prevent any progress until forever. (OK, our future AI-Overlords could change that possibly). But who cares about the status quo? The market insists on it. So any attempt at resistance is therefore futile. ___ Please excuse the slight amounts of sarcasm. I just couldn't hold back. And seriously: There may be some jokes hidden in here. If you try you'll recognize one or two of them, I bet… :-D
- highwaylights 4y ago
  Qubes is a good product while simultaneously being both the best and an objectively poor solution to a problem that shouldn't exist. That's how much of a mess the situation is. Qubes is sandboxing at a machine level by putting every application set into it's own O/S. Is that in any way clean or ideal? Not at all. But it's necessary if you don't trust your own O/S not to have been compromised by the software running inside it. I get the arguments against centralised software distribution - it encourages monopolistic behaviour and removes user freedom - but it does at least make a problem of this nature fixable if you can enforce compliance to breaking changes at distribution time. I'd like to think a new layer could be added to Linux or BSD that would marshall this kind of compliance centrally without deliberately conflating payment into it, but I've no idea how you'd get widespread adoption of something like that even if you could organise to implement it. You'd also likely need to implement code-signing everywhere which was such a challenge in the past that (at least in the Linux kernel) it was abandoned. A similar model to how domain registration works for white-listing might make sense here, in that it's not centralised - but it's not fully decentralised either - and at some point there needs to be a process to onboard new authorities who everyone needs to trust, at which point it's a slippery slope to self-certification.
- MAGZine 4y ago
  > It makes me sad that we are likely not going to see any new fundamental design rethink for security's sake in mainstream operating systems. It is cost prohibitive at this point to do something that gets security right for the world of 2022 and yet not break all the apps which would never be rewritten! I don't think that's the case though. Microsoft overhauled the entire security post of windows during Vista. It wasn't a good OS when it came out, but Windows is much better for it. But yes, if you're going to start from the ground up, you're going to lose a bunch of functionality. Not only due to the nature of rewrites, but also because of "what new limitations does the security model imply"?
Linda703 4y ago
[dead]
benreesman 4y ago
Oh that hurts to watch, brutal. The "Pwn" button helps keep it light, and I'm definitely stealing that, but ouch. Can someone who knows mac OS development educate me about why it would be broken/expensive/inadequate to just page the application's mapped pages to disk? I gather at least on the lower memory Apple Silicon devices that swap is pretty aggressive even for running applications?
- ridiculous_fish 4y ago
  I worked on AppKit's persistent state feature. One of its primary uses is persisting UI state across app restarts, for example when performing a software update. Simply writing out memory to disk would "persist" data like Mach ports or file descriptors, which would no longer be valid when the app is re-launched.
  - benreesman 4y ago
    Makes sense! Thanks for the explanation.
  - amluto 4y ago
    Would it be practical to prevent apps from writing to other apps’ persisted state?
    - ridiculous_fish 4y ago
      Yes of course, by design apps write their state into their own sandbox in the filesystem, and trust the OS to enforce security boundaries.
      - amluto 4y ago
        Then how does the entitlement escalation part of the exploit work? The writeup sure makes it sound like any app can write to the persisted state of another app.
        4y ago
pram 4y ago
The 'Reopen windows' feature is a complete crapshoot on what the app actually does when it comes back up, so I never use it. It has always been half baked on OSX, and seems to also add weird complexity. Honestly what is the benefit? A computer is off, on, or sleeping. All of that worked fine for years. I don't get it.
- Syonyk 4y ago
  > Honestly what is the benefit? Clearly, you're not in the business of selling high performance, modern computers with 8GB of RAM... Apple's base amounts of RAM are stingy at best.
- nicolas_t 4y ago
  Side note, I really would love it if there was à way to stop os x from reopening all windows on the next boot after it crashes. I hate that so much.
  - interpol_p 4y ago
    Perhaps the "Close windows when quitting an app" setting in System Preferences -> General may do it?
    - hungryforcodes 4y ago
      Would be nice if it actually worked though...
    - deleted 4y ago
      [deleted]
  - deleted 4y ago
    [deleted]
  - hk1337 4y ago
     > Restart > https://i.imgur.com/uPTJyyS.png https://i.imgur.com/uPTJyyS.png That's always done it for me. It's one of the first things I uncheck on a new Mac.
bawolff 4y ago
> In PHP, exploitability [of untrusted deserialization] for RCE is rare. I think that is disputable. Anyways, great write up
- deleted 4y ago
  [deleted]
deepdriver 4y ago
Related to this, is there an easy way to run arbitrary programs in the macOS sandbox? AFAIK sandboxing is opt-in for app developers at the moment. Does manual invocation of sandbox-exec on the command line still work, and are there GUI helpers for running arbitrary apps with this tool? Edit: Apparently sandbox-exec is still usable, just not (publicly) well-documented. Would be nice of Apple to make sandboxing easier for regular users running untrusted apps that don't opt-in to the sandbox. I’m thinking of Firefox and Firefox extensions in particular. https://7402.org/blog/2020/macos-sandboxing-of-folder.html https://7402.org/blog/2020/macos-sandboxing-of-folder.html >The only non-folkloric documentation is found in the man page for sandbox-exec [...] >Sandbox documentation has been a moving target over the years. Because it is a private interface, Apple is under no obligation to maintain forward or backward compatibility. Take note of the publication date of any information found online. >Just to be clear, the sandbox profile format is not documented for third party use. Feel free to experiment with this stuff, but please don’t try to ship a product based on it.
zbird 4y ago
How much did Apple pay for the vuln report?
- hericium 4y ago
  The lawsuit is being sketched as we speak.
shp0ngle 4y ago
> Applications can now opt-in to requiring secure coding for their saved state by returning TRUE from this method. Unless an app opts in, it will keep allowing non-secure coding, which means process injection might remain possible. > This vulnerability will therefore be present for as long as there is backwards compatibility with older macOS applications! This sounds… really really bad?
- shp0ngle 4y ago
  also the first footnote is very bizarre
- jshier 4y ago
  NSSecureCoding is so old at this point (macOS 10.8, 2012) that anyone still writing Obj-C who hasn't adopted it is essentially committing malpractice.
  - Sohcahtoa82 4y ago
    I mean...people are still writing code with textbook SQL injection and XSS vulnerabilities. A startling number of developers know nothing about security.
- deleted 4y ago
  [deleted]
akersten 4y ago
Surely there is a better fix to a deserialization exploit than just making every new app implement `bool dontBeHackable { return true; }`?? Even just, I don't know, forcing all builds to silently include this property in the compiled output - I mean, interacting with OS app state data files should be abstracted away from the programmer anyway, so it shouldn't matter if they're signed/encrypted behind the scenes, just handle it automatically, right?
- brundolf 4y ago
  It could break a bunch of apps. Could argue that the user should get to decide, but it would have consequences to just do it across the board automatically
- jshier 4y ago
  Apple originally intended to require NSSecureCoding in some way after it was introduced in macOS 10.8 (2012) but constantly delayed those plans due to the compatibility issues sibling mentioned.
  - crazysim 4y ago
    Did apple lose their courage? Maybe they should throw a dialog not unlike the 32-bit x86 deprecation
- michelb 4y ago
  Could this simply be a 'quick fix'? Can't imagine this being the definitive solution to this.
nuker 4y ago
Related, yesterday: https://news.ycombinator.com/item?id=32458878 https://news.ycombinator.com/item?id=32458878
- EE84M3i 4y ago
  I'm confused, could you clarify how these are related? These seemed like different vulnerabilities to me, but I don't know much about OS X.
  - nuker 4y ago
    Related because both allow code injection into a signed app, but mine uses disable-library-validation entitlement method and this uses SecureRestorableState method.
yardstick 4y ago
> It is unclear what security the AES encryption here is meant to add, as the key is stored right next to it. There is no MAC, so no integrity check for the ciphertext I imagine this is to prevent accidental disclosure of sensitive data through basic tools (only) like grep, and Spotlight. Also to prevent layman attempts at tweaking the files in a text editor like one used to do tweaking save files as a kid. But not to protect against dedicated attackers.
- londons_explore 4y ago
  This type of security is bad. Either something should be possible, and easy for anyone to do... Or it should not be possible, and protected by real cryptography. Hiding something with ROT-13 just 'so it doesn't show up in grep' is a bad idea.
  - megous 4y ago
    If data is to be used locally, it has to be encryptable and decryptable locally with just resources accessible locally, so it's pretty much not secureable from local software.
    - londons_explore 4y ago
      You can still secure things with local keys managed in eg. a keychain that checks the identity/entitlements/permissions of the caller before giving out the keys.
      - megous 4y ago
        That just translates to a slightly longer exploit chain in practice. It's not a fundamental obsatacle.
  - TheSpiceIsLife 4y ago
    A safe can be opened, so should safes not have doors? It is often good to leave keys right next to a locked lock.
hericium 4y ago
What an incompetent shitshow. I don't believe this will impact AAPL's price though. Shareholders and ad sellers are the only "customers"/"users" Cook's Apple is interested in and works for and news of this vulnerability will be shushed or soothed outside of tech forums. Whether this will be somehow fixed (Dear Cook's Apple, consider starting with not keeping decryption keys together with encrypted data, duh) or ABI/compatibility will get broken, Apple's marketing will sell the news to shareholders as an improvement and the magic of capitalism will boost the price.
- kortilla 4y ago
  >don't believe this will impact AAPL's price though. Shareholders and ad sellers are the only "customers"/"users" This is completely wrong. Apple makes very little of its revenue from advertising. Their cash cow customers are iPhone users.
  - hericium 4y ago
    Like many/most public companies, Apple doesn't work for cash cows (it's the other way around) but their real customers - shareholders.
    - mrex 4y ago
      Hmm. What public companies do you know of that don't work for their shareholders?
      - hericium 4y ago
        Fresh IPOs have products quality which made them IPOs. It gets downhill around that time and pro-user changes to pro-shareholder, which are very often in opposition.
    - kortilla 4y ago
      Shareholders are not customers FFS. Stop repeating that like it’s some grand insight. Shareholders are owners and shareholders want money. The way to get money is from customers. You don’t make money from shareholders unless you’re running a Ponzi scheme.
Ehekatl 4y ago
Just wrote a email to product-security@apple.com User should able to disable "saved state" when app does not implement `applicationSupportsSecureRestorableState`.
- Ehekatl 4y ago
  when "saved state" works it help with certain siutation, but the convenience it bring can't not justfy the security cost. Besides, this mechanism is problemmactic under certain situation (AFPS disk full, power cut off, OS crash, etc), there will have corrupted state file, and may leads to data lose. I'm still remember this problem happen to Atom, cause me a lot of data loss, in the end, apps will have their way of store temporary state file, without relying on macOS's build-in state, like office and all other modern code editor.
- deleted 4y ago
  [deleted]
28194608 4y ago
- londons_explore 4y ago
  So you're experimenting with your bot on HN hey.... Well it isn't welcome.... And even if it were welcome, it's spewing random junk from the training set.
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
noduerme 4y ago
>> Process injection is the ability for one process to execute code in a different process This is the kind of absurd, foundation-shaking statement that, as someone who's been coding since I was 7 (in 1987..) feels purely nauseating. Although I sort of know the answer, my first question is how did we reach the point where something so fundamental could be so insecure and distributed to so many people?
- 28194608 4y ago
  - noduerme 4y ago
    That's impressive. still not process injection unless it's still repeating itself every time I reload ;) [edit] oops. I reloaded. What was that script kiddy running against the server that generated all that text? Couldn't have been rendered on the client
- antientropic 4y ago
  This is what happens when a new security model is retrofitted onto an existing one. In the original Unix security model, there was no security concern with this (except maybe for chroot environments): it didn't allow a process to do something it couldn't otherwise do, since all processes owned by a uid had exactly the same rights. Now that we've started sandboxing user processes in various ways on macOS and Linux, that's no longer the case, and we suddenly need to crack down on useful tools like strace and gdb.
  - noduerme 4y ago
    Sorry... this is above my pay grade, but I still think of processes as running on a single thread, reserving memory and being mostly inviolable other than maybe sampling what they're holding at the moment. How does giving a tool the ability to analyze a thread allow it to inject code into the process as it's running? Forgive me if I'm just way behind but isn't the kernel of any modern OS supposed to prevent exactly that thing from happening?
Angostura 4y ago
Just a note of appreciation to the author for the clear, accessible way this is written up. Understandable by semi-technical people like me.
archi42 4y ago
Backwards compatibility over security, reminds me of a certain, popular OS. They could enforce it for all applications signed after a certain date and/or mark the unsafe method as deprecated. This would still not prevent downgrade attacks for a while, but at least offer a path forward.
dano 4y ago
Small correction to the article, it is the Transparency, Consent and Control (TCC) framework rather than Trust, Transparency, and Control. More here https://eclecticlight.co/2019/07/22/mojaves-privacy-consent-works-behind-your-back/ https://eclecticlight.co/2019/07/22/mojaves-privacy-consent-...
highwaylights 4y ago
Question from reading the article, although I might have missed the response. Is a user's latest version of macOS still vulnerable to this exploit if they're running any applications that do not return true for this boolean? (i.e. does this mean older apps still make the entire machine vulnerable?) If so, is there a means for the users to enforce this flag globally and just deal with the crashes if an app tries to do something that relies on this privilege?
- devenvdev 4y ago
  Seems like old apps are vulnerable: > This vulnerability will therefore be present for as long as there is backwards compatibility with older macOS applications!
  - asdff 4y ago
    Just what apple needed, another casus belli to remove more backward compatibilty from macos. I still am on mojave out of principle.
docmars 4y ago
Something something TLA backdoor much?
musicale 4y ago
Presumably Apple has restricted the entitlement processing to disallow downgrades/SIP bypass of the boot OS? Personally I'm fine with requiring recovery mode for downgrades, and maybe for blacklisted upgrades as well. IIRC they do something like revoking/disabling old iOS installers, but that seems a bit extreme for macOS.

606 points by afrcnc 4y ago

>Changing a security model that has been used for decades to a more restrictive model is difficult, especially in something as complicated as macOS. Attaching debuggers is just one example, there are many similar techniques that could be used to inject code into a different process. Apple has squashed many of these techniques, but many other ones are likely still undiscovered. > Aside from Apple’s own code, these vulnerabilities could also occur in third-party software. It’s quite common to find a process injection vulnerability in a specific application, which means that the permissions (TCC permissions and entitlements) of that application are up for grabs for all other processes. Getting those fixed is a difficult process, because many third-party developers are not familiar with this new security model. Reporting these vulnerabilities often requires fully explaining this new model! Especially Electron applications are infamous for being easy to inject into, as it is possible to replace their JavaScript files without invalidating the code signature. It makes me sad that we are likely not going to see any new fundamental design rethink for security's sake in mainstream operating systems. It is cost prohibitive at this point to do something that gets security right for the world of 2022 and yet not break all the apps which would never be rewritten! Mobile OSes were a good break off point as far as security goes but that came with a lot of functionality sacrifice. Although something like QubesOS can theoretically dream of being semi-mainstream with support from hardware and OSS OS vendors like RH/Suse/Canonical or even Microsoft.

olliej 4y ago
Fuchsia does a pure capability model, and resources, even as basic as the file system are provided through handles - and your file system handle is a handle to what would be a directory elsewhere, but that is the entire file system so it’s not a matter of finding a traversal exploit. In principle you could do something similar with the Mac/iOS sandbox by starting a process with a compute only sandbox, and then provide it with specific sandbox entitlements (from the parent) which includes specific file systems, however they still in principle can see a full version of the fs. And yeah, any OS that isn’t completely new is burdened with support for old apps, but then iOS which used its newness to have a stronger base security model is constantly beaten up for that model.
- blinkingled 4y ago
  Ah, I forgot about Fuchsia - https://arxiv.org/pdf/2108.04183.pdf https://arxiv.org/pdf/2108.04183.pdf seems to do a good job of explaining the security architecture without complicating things. With Google's backing (if they don't lose interest that is) and the potential to take over Nest/Chromebook/Android devices it might go farther than most new OS experiments.
eru 4y ago
> It is cost prohibitive at this point to do something that gets security right for the world of 2022 and yet not break all the apps which would never be rewritten! You could quarantine your old applications to their own individual VMs, while newer programs can make use of your shiny new security features?
- blinkingled 4y ago
  Sort of like Fuchsia/QubesOS combo, interesting.
  - eru 4y ago
    Maybe, I don't know these. I was just pointing out that we can have both progress and backwards compatibility. Just like we can still play old games via dosbox, but that doesn't mean we have to run DOS as our main OS.
- KerrAvon 4y ago
  Harder than it sounds, though. You still have to be able to communicate with other processes to present the user with a usable UI, so the isolation is never really complete. There are lots of variations on this theme and they all have to compromise in some way.
  - hn_throwaway_99 4y ago
    True, but Apple still did it to allow Classic Mac apps to run on OS X when the initial version of OS X was released.
  - eru 4y ago
    Oh, it's definitely no walk in the park. But more realistic than rewriting all old programs in one go.
  - samus 4y ago
    It's perfectly possible to have that with something like the X window system. The irony is that this protocol gives applications way too many capabilities. But Wayland is a chance to fix that for good and finally have proper compartmentalisation in the GUI.
Syonyk 4y ago
> Although something like QubesOS can theoretically dream of being semi-mainstream with support from hardware and OSS OS vendors like RH/Suse/Canonical or even Microsoft. I'm trying to encourage as many people as I can to run it, or at least play with it for some while to gain familiarity with it. Properly applied, I think it does add quite a bit of useful practical security... though it's not going to automatically solve all problems. I like the silos of compromise, at least, and you can do high risk things (like "anything web") in disposable VMs that reset on VM power cycle. My only major concern with Qubes is that I've not decided if it's weird and niche enough to be mostly left alone by the 0day markets, or if it's a super high priority, high value target to attack because of the type of people who are likely to use it. I'd like to see an ARM port of it, because Xen on ARM is quite a bit simpler than Xen on x86, but the hardware to run that doesn't quite exist yet. Maybe with the RK3588... The fundamental problem here is that software developers (and I'm guilty here too, as much as anyone in that industry) tend to view complexity as a one way ratchet function - add features. Add features. Add features. Add knobs. And when it comes crashing down around your ears, "add security" (in the form of sandboxes, or process isolation, or... https://xkcd.com/2044/ https://xkcd.com/2044/ applies here). And then it turns out that "adding complexity to solve problems created by complexity" isn't a strategy with a great long term success rate. I'm slightly encouraged by Apple admitting, as clearly as they ever admit anything, that this strategy isn't working - with their Lockdown mode, that's "only for people with the most extreme threats, blah blah blah," and I'd expect anyone in the security or software industry to turn that on basically as soon as they get iOS 16 and not look back. Or install the beta to give that option.
- dmz73 4y ago
  I have tried the QubesOS and boy does it bring back memories of Windows being called Pentium to 286 converter. It is slow as molasses on hardware where even Windows 10 and Gnome are both fast and to make it usable you have to keep relaxing the security to the point where it is probably less secure than regular OS. And don't even bother if you have to use scaling other than 100%, sure you can scale the DOM0 but the rest of the VMs are not scaled and there is no documentation on how to do it. What we need are simple sandboxes that isolate GUI applications into chroot environment and keep them away from other applications and documents.
userbinator 4y ago
It makes me sad that we are likely not going to see any new fundamental design rethink for security's sake in mainstream operating systems. Contrarily, that makes me happy because if that happens we are really going to lose what little computing freedom we have left, as it will only make the walled garden silos even stronger.
- matheusmoreira 4y ago
  Yeah. The problem with all these security innovations is they allow corporations to seize control. The ability to debug and intercept is also the ability to reverse engineer and override. We need secure software that empowers us, not some secure walled garden.
- eastbound 4y ago
  It’s hard to sign off SOC2 compliance when you know that npm and maven packages can be introduced by any mistake on your team and contain an “Upload all files from HDD to a rogue server” script. I’d need to operate administrative files (customer records, contracts, accounting) on a separate machine from dev… App sandboxing is… the way it will go, for insurance reasons.
  - wila 4y ago
    > I’d need to operate administrative files (customer records, contracts, accounting) on a separate machine from dev You're saying that like it is a bad thing? A developer probably shouldn't have access to all that live data anyways.
    - eastbound 4y ago
      As a founder-developer of a company of 3, would you expect me to have 2 computers, for the security of customer data? It’s an interesting idea, I’m just asking.
      - skrtskrt 4y ago
        For such a small company I would probably expect that data like that would probably just live in a cloud service like GSuite that’s already SOC2 compliant, then if you’re running software integrations against that data, you’re spinning up isolated SOC2-compliant cloud servers to do so. Unfortunately unless you get ridiculously creative and put in a bunch of extra time instead of cloud service spend, SOC2 compliance is gonna be expensive
solarkraft 4y ago
> Mobile OSes were a good break off point as far as security goes but that came with a lot of functionality sacrifice. I have a tiny bit of hope that they'll eventually be able to replace desktop OSes through virtualization. It's actually what I long thought Apple would do with iPad OS (why else put in an M1?).
mhoad 4y ago
Google’s upcoming Fuchsia OS has an entirely new security model that looks really solid. I imagine it’s still a few years away however from any kind of desktop usage.
londons_explore 4y ago
I think a lot of users would be fine with apps being fully silo'ed from eachother with the exception of being able to copy and paste between them, and have 'File Open' dialog boxes able to access files from anywhere. Every other kind of interaction between seperate applications can be blocked without breaking much functionality. And you can limit breakage further by running all 'legacy' applications in the same silo, and only running new applications disconnected from eachother.
- noduerme 4y ago
  Literally any other kind of interaction between applications feels like the apps are spying on me. I don't even want one to suggest which app I should open for a doc. Mac OS has taken security in a strange direction where you can't change the suffix of a file without exposing possible vulnerabilities by apps automatically opening it - and the backstop is supposed to be validating all applications through your "apple account" (whatever that is?). (although in some sense the suffix and permissions flaws have been around since System 7).
deleted 4y ago
[deleted]
still_grokking 4y ago
Well, GNU Hurd 2 is going to be released real soon now. It will fix all the issues with current OS architectures. And than, at some point Google's Fuchsia will also surface in mainstream likely. Both systems will bring capability-security. (You know, almost like seL4, only less secure). A technology that wasn't used until now, even it's available for almost 50 years, and would solve almost all security problems of computers. We could have had that in fact directly supported by hardware almost four decades ago… But the market didn't like that. The problem is that there is and won't be any progress in computer technology. It's like that since at least one hundred years. We're buried in the von Neumann local "optimum" since than… As long as this does not change we're doomed to have crappy, inefficient, and insecure computers. The invisible hand will just prevent any progress until forever. (OK, our future AI-Overlords could change that possibly). But who cares about the status quo? The market insists on it. So any attempt at resistance is therefore futile. ___ Please excuse the slight amounts of sarcasm. I just couldn't hold back. And seriously: There may be some jokes hidden in here. If you try you'll recognize one or two of them, I bet… :-D
highwaylights 4y ago
Qubes is a good product while simultaneously being both the best and an objectively poor solution to a problem that shouldn't exist. That's how much of a mess the situation is. Qubes is sandboxing at a machine level by putting every application set into it's own O/S. Is that in any way clean or ideal? Not at all. But it's necessary if you don't trust your own O/S not to have been compromised by the software running inside it. I get the arguments against centralised software distribution - it encourages monopolistic behaviour and removes user freedom - but it does at least make a problem of this nature fixable if you can enforce compliance to breaking changes at distribution time. I'd like to think a new layer could be added to Linux or BSD that would marshall this kind of compliance centrally without deliberately conflating payment into it, but I've no idea how you'd get widespread adoption of something like that even if you could organise to implement it. You'd also likely need to implement code-signing everywhere which was such a challenge in the past that (at least in the Linux kernel) it was abandoned. A similar model to how domain registration works for white-listing might make sense here, in that it's not centralised - but it's not fully decentralised either - and at some point there needs to be a process to onboard new authorities who everyone needs to trust, at which point it's a slippery slope to self-certification.
MAGZine 4y ago
> It makes me sad that we are likely not going to see any new fundamental design rethink for security's sake in mainstream operating systems. It is cost prohibitive at this point to do something that gets security right for the world of 2022 and yet not break all the apps which would never be rewritten! I don't think that's the case though. Microsoft overhauled the entire security post of windows during Vista. It wasn't a good OS when it came out, but Windows is much better for it. But yes, if you're going to start from the ground up, you're going to lose a bunch of functionality. Not only due to the nature of rewrites, but also because of "what new limitations does the security model imply"?

Linda703 4y ago

[dead]

benreesman 4y ago

Oh that hurts to watch, brutal. The "Pwn" button helps keep it light, and I'm definitely stealing that, but ouch. Can someone who knows mac OS development educate me about why it would be broken/expensive/inadequate to just page the application's mapped pages to disk? I gather at least on the lower memory Apple Silicon devices that swap is pretty aggressive even for running applications?

ridiculous_fish 4y ago
I worked on AppKit's persistent state feature. One of its primary uses is persisting UI state across app restarts, for example when performing a software update. Simply writing out memory to disk would "persist" data like Mach ports or file descriptors, which would no longer be valid when the app is re-launched.
- benreesman 4y ago
  Makes sense! Thanks for the explanation.
- amluto 4y ago
  Would it be practical to prevent apps from writing to other apps’ persisted state?
  - ridiculous_fish 4y ago
    Yes of course, by design apps write their state into their own sandbox in the filesystem, and trust the OS to enforce security boundaries.
    - amluto 4y ago
      Then how does the entitlement escalation part of the exploit work? The writeup sure makes it sound like any app can write to the persisted state of another app.
      - 4y ago

pram 4y ago

The 'Reopen windows' feature is a complete crapshoot on what the app actually does when it comes back up, so I never use it. It has always been half baked on OSX, and seems to also add weird complexity. Honestly what is the benefit? A computer is off, on, or sleeping. All of that worked fine for years. I don't get it.

Syonyk 4y ago
> Honestly what is the benefit? Clearly, you're not in the business of selling high performance, modern computers with 8GB of RAM... Apple's base amounts of RAM are stingy at best.
nicolas_t 4y ago
Side note, I really would love it if there was à way to stop os x from reopening all windows on the next boot after it crashes. I hate that so much.
- interpol_p 4y ago
  Perhaps the "Close windows when quitting an app" setting in System Preferences -> General may do it?
  - hungryforcodes 4y ago
    Would be nice if it actually worked though...
  - deleted 4y ago
    [deleted]
- deleted 4y ago
  [deleted]
- hk1337 4y ago
   > Restart > https://i.imgur.com/uPTJyyS.png https://i.imgur.com/uPTJyyS.png That's always done it for me. It's one of the first things I uncheck on a new Mac.

bawolff 4y ago

> In PHP, exploitability [of untrusted deserialization] for RCE is rare. I think that is disputable. Anyways, great write up

deleted 4y ago
[deleted]

deepdriver 4y ago

Related to this, is there an easy way to run arbitrary programs in the macOS sandbox? AFAIK sandboxing is opt-in for app developers at the moment. Does manual invocation of sandbox-exec on the command line still work, and are there GUI helpers for running arbitrary apps with this tool? Edit: Apparently sandbox-exec is still usable, just not (publicly) well-documented. Would be nice of Apple to make sandboxing easier for regular users running untrusted apps that don't opt-in to the sandbox. I’m thinking of Firefox and Firefox extensions in particular. https://7402.org/blog/2020/macos-sandboxing-of-folder.html https://7402.org/blog/2020/macos-sandboxing-of-folder.html >The only non-folkloric documentation is found in the man page for sandbox-exec [...] >Sandbox documentation has been a moving target over the years. Because it is a private interface, Apple is under no obligation to maintain forward or backward compatibility. Take note of the publication date of any information found online. >Just to be clear, the sandbox profile format is not documented for third party use. Feel free to experiment with this stuff, but please don’t try to ship a product based on it.

zbird 4y ago

How much did Apple pay for the vuln report?

hericium 4y ago
The lawsuit is being sketched as we speak.

shp0ngle 4y ago

> Applications can now opt-in to requiring secure coding for their saved state by returning TRUE from this method. Unless an app opts in, it will keep allowing non-secure coding, which means process injection might remain possible. > This vulnerability will therefore be present for as long as there is backwards compatibility with older macOS applications! This sounds… really really bad?

shp0ngle 4y ago
also the first footnote is very bizarre
jshier 4y ago
NSSecureCoding is so old at this point (macOS 10.8, 2012) that anyone still writing Obj-C who hasn't adopted it is essentially committing malpractice.
- Sohcahtoa82 4y ago
  I mean...people are still writing code with textbook SQL injection and XSS vulnerabilities. A startling number of developers know nothing about security.
deleted 4y ago
[deleted]

akersten 4y ago

Surely there is a better fix to a deserialization exploit than just making every new app implement `bool dontBeHackable { return true; }`?? Even just, I don't know, forcing all builds to silently include this property in the compiled output - I mean, interacting with OS app state data files should be abstracted away from the programmer anyway, so it shouldn't matter if they're signed/encrypted behind the scenes, just handle it automatically, right?

brundolf 4y ago
It could break a bunch of apps. Could argue that the user should get to decide, but it would have consequences to just do it across the board automatically
jshier 4y ago
Apple originally intended to require NSSecureCoding in some way after it was introduced in macOS 10.8 (2012) but constantly delayed those plans due to the compatibility issues sibling mentioned.
- crazysim 4y ago
  Did apple lose their courage? Maybe they should throw a dialog not unlike the 32-bit x86 deprecation
michelb 4y ago
Could this simply be a 'quick fix'? Can't imagine this being the definitive solution to this.

nuker 4y ago

Related, yesterday: https://news.ycombinator.com/item?id=32458878 https://news.ycombinator.com/item?id=32458878

EE84M3i 4y ago
I'm confused, could you clarify how these are related? These seemed like different vulnerabilities to me, but I don't know much about OS X.
- nuker 4y ago
  Related because both allow code injection into a signed app, but mine uses disable-library-validation entitlement method and this uses SecureRestorableState method.

yardstick 4y ago

> It is unclear what security the AES encryption here is meant to add, as the key is stored right next to it. There is no MAC, so no integrity check for the ciphertext I imagine this is to prevent accidental disclosure of sensitive data through basic tools (only) like grep, and Spotlight. Also to prevent layman attempts at tweaking the files in a text editor like one used to do tweaking save files as a kid. But not to protect against dedicated attackers.

londons_explore 4y ago
This type of security is bad. Either something should be possible, and easy for anyone to do... Or it should not be possible, and protected by real cryptography. Hiding something with ROT-13 just 'so it doesn't show up in grep' is a bad idea.
- megous 4y ago
  If data is to be used locally, it has to be encryptable and decryptable locally with just resources accessible locally, so it's pretty much not secureable from local software.
  - londons_explore 4y ago
    You can still secure things with local keys managed in eg. a keychain that checks the identity/entitlements/permissions of the caller before giving out the keys.
    - megous 4y ago
      That just translates to a slightly longer exploit chain in practice. It's not a fundamental obsatacle.
- TheSpiceIsLife 4y ago
  A safe can be opened, so should safes not have doors? It is often good to leave keys right next to a locked lock.

hericium 4y ago

What an incompetent shitshow. I don't believe this will impact AAPL's price though. Shareholders and ad sellers are the only "customers"/"users" Cook's Apple is interested in and works for and news of this vulnerability will be shushed or soothed outside of tech forums. Whether this will be somehow fixed (Dear Cook's Apple, consider starting with not keeping decryption keys together with encrypted data, duh) or ABI/compatibility will get broken, Apple's marketing will sell the news to shareholders as an improvement and the magic of capitalism will boost the price.

kortilla 4y ago
>don't believe this will impact AAPL's price though. Shareholders and ad sellers are the only "customers"/"users" This is completely wrong. Apple makes very little of its revenue from advertising. Their cash cow customers are iPhone users.
- hericium 4y ago
  Like many/most public companies, Apple doesn't work for cash cows (it's the other way around) but their real customers - shareholders.
  - mrex 4y ago
    Hmm. What public companies do you know of that don't work for their shareholders?
    - hericium 4y ago
      Fresh IPOs have products quality which made them IPOs. It gets downhill around that time and pro-user changes to pro-shareholder, which are very often in opposition.
  - kortilla 4y ago
    Shareholders are not customers FFS. Stop repeating that like it’s some grand insight. Shareholders are owners and shareholders want money. The way to get money is from customers. You don’t make money from shareholders unless you’re running a Ponzi scheme.

Ehekatl 4y ago

Just wrote a email to product-security@apple.com User should able to disable "saved state" when app does not implement `applicationSupportsSecureRestorableState`.

Ehekatl 4y ago
when "saved state" works it help with certain siutation, but the convenience it bring can't not justfy the security cost. Besides, this mechanism is problemmactic under certain situation (AFPS disk full, power cut off, OS crash, etc), there will have corrupted state file, and may leads to data lose. I'm still remember this problem happen to Atom, cause me a lot of data loss, in the end, apps will have their way of store temporary state file, without relying on macOS's build-in state, like office and all other modern code editor.
deleted 4y ago
[deleted]

28194608 4y ago

londons_explore 4y ago
So you're experimenting with your bot on HN hey.... Well it isn't welcome.... And even if it were welcome, it's spewing random junk from the training set.

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

noduerme 4y ago

>> Process injection is the ability for one process to execute code in a different process This is the kind of absurd, foundation-shaking statement that, as someone who's been coding since I was 7 (in 1987..) feels purely nauseating. Although I sort of know the answer, my first question is how did we reach the point where something so fundamental could be so insecure and distributed to so many people?

28194608 4y ago
- noduerme 4y ago
  That's impressive. still not process injection unless it's still repeating itself every time I reload ;) [edit] oops. I reloaded. What was that script kiddy running against the server that generated all that text? Couldn't have been rendered on the client
antientropic 4y ago
This is what happens when a new security model is retrofitted onto an existing one. In the original Unix security model, there was no security concern with this (except maybe for chroot environments): it didn't allow a process to do something it couldn't otherwise do, since all processes owned by a uid had exactly the same rights. Now that we've started sandboxing user processes in various ways on macOS and Linux, that's no longer the case, and we suddenly need to crack down on useful tools like strace and gdb.
- noduerme 4y ago
  Sorry... this is above my pay grade, but I still think of processes as running on a single thread, reserving memory and being mostly inviolable other than maybe sampling what they're holding at the moment. How does giving a tool the ability to analyze a thread allow it to inject code into the process as it's running? Forgive me if I'm just way behind but isn't the kernel of any modern OS supposed to prevent exactly that thing from happening?

Angostura 4y ago

Just a note of appreciation to the author for the clear, accessible way this is written up. Understandable by semi-technical people like me.

archi42 4y ago

Backwards compatibility over security, reminds me of a certain, popular OS. They could enforce it for all applications signed after a certain date and/or mark the unsafe method as deprecated. This would still not prevent downgrade attacks for a while, but at least offer a path forward.

dano 4y ago

Small correction to the article, it is the Transparency, Consent and Control (TCC) framework rather than Trust, Transparency, and Control. More here https://eclecticlight.co/2019/07/22/mojaves-privacy-consent-works-behind-your-back/ https://eclecticlight.co/2019/07/22/mojaves-privacy-consent-...

highwaylights 4y ago

Question from reading the article, although I might have missed the response. Is a user's latest version of macOS still vulnerable to this exploit if they're running any applications that do not return true for this boolean? (i.e. does this mean older apps still make the entire machine vulnerable?) If so, is there a means for the users to enforce this flag globally and just deal with the crashes if an app tries to do something that relies on this privilege?

devenvdev 4y ago
Seems like old apps are vulnerable: > This vulnerability will therefore be present for as long as there is backwards compatibility with older macOS applications!
- asdff 4y ago
  Just what apple needed, another casus belli to remove more backward compatibilty from macos. I still am on mojave out of principle.

docmars 4y ago

Something something TLA backdoor much?

musicale 4y ago

Presumably Apple has restricted the entitlement processing to disallow downgrades/SIP bypass of the boot OS? Personally I'm fine with requiring recovery mode for downgrades, and maybe for blacklisted upgrades as well. IIRC they do something like revoking/disabling old iOS installers, but that seems a bit extreme for macOS.