App Management is a new macOS security feature in Ventura introduced at WWDC last year:
If an app is modified by something that isn't signed by the same development team and isn't allowed by an NSUpdateSecurityPolicy, macOS will block the modification and notify the user that an app wants to manage other apps. Clicking on the notification sends people to System Settings, where they can allow an app to update and modify other apps.
There's a System Settings pane for App Management in the Privacy & Security section:
Back in October I wrote about How macOS Ventura App Management works and doesn't work, but I kept one part a secret:
in the process of writing this blog post, I found a new App Management bypass that doesn't require full disk access. I won't discuss the details of that here (I sent them to Apple Product Security a few days ago)
Specifically, I reported the bypass on October 19, 2022, Apple Product Security acknowledged receiving my report on October 21, and Apple released macOS Ventura to the public on October 24. Today I will discuss the details of the bypass, not because it's been fixed in macOS—in fact it hasn't been fixed yet—but rather because I've lost all confidence in Apple to address the issue in a timely manner. In other words, I'm dropping a 0day. We're at ten months and counting, with no end in sight, and I feel that's absurd. It should be noted that by disclosing the issue publicly, I'm sacrificing the opportunity to receive an Apple Security Bounty. On the other hand, Apple has made no promise to pay anything, and by policy they refuse to pay or even calculate a bounty until after an issue is fixed in a public software update, so I could be waiting forever for nothing. Up until now, Apple has been "buying" my silence for $0 and only the vague possibility of some future payment.
(Edit: On reflection, perhaps I'm not using the term "0day" correctly. But I've already published this blog post, and as I say at the end, I'm not professional security researcher, so I plead ignorance.)
Strangely, I was credited, along with a few others, in the security release notes for macOS Ventura 13.4:
Sandbox
Available for: macOS Ventura
Impact: An app may be able to retain access to system configuration files even after its permission is revoked
Description: An authorization issue was addressed with improved state management.
CVE-2023-32357: Yiğit Can YILMAZ (@yilmazcanyigit), Koh M. Nakagawa of FFRI Security, Inc., Kirin (@Pwnrin), Jeff Johnson (underpassapp.com), and Csaba Fitzl (@theevilbit) of Offensive Security
Nonetheless, CVE-2023-32357 is not the issue that I reported to Apple, which remains unfixed in macOS Ventura 13.5.1, the latest version as of today. Apple did tell me that my report was helpful in fixing CVE-2023-32357, but they declined to pay me a bounty for it, because I was not the first person to report the issue. I don't actually know the details of that issue, and Apple refused to share the details with me, despite the fact that it's already been fixed.
In retrospect, I regret participating in the Apple Security Bounty program. It has been a giant, frustrating waste of time, and I wish I had just dropped this 0day on October 24 of last year when Ventura was released. I suspect that if I had done so, Apple would have found a way to address the issue already in Ventura. Thus, I feel that my prolonged silence has not protected Mac users. The standard practice in reporting a security vulnerability is to give the vendor 90 days to address the issue, and I've given Apple vastly more time than expected.
With the introductory material out of the way, let's look at the details of the bypass. In my earlier blog post, I said there are at least six different ways for an app to acquire app management permissions:
NSUpdateSecurityPolicy in the modified app's Info.plist filecom.apple.macl extended attributeI'm finally un-redacting the 6th way, and ironically, it's the app sandbox. I discovered—almost by accident—that a sandboxed app could modify files that it shouldn't be able to modify: files inside the bundle of a notarized app that were supposedly protected by App Management security.
Of course a sandboxed app has somewhat limited access to the file system, although it's notable that the /Applications folder is included within the sandbox. Regardless, the initial extent of the sandbox is not really an issue for an attacker, because a non-sandboxed app can open files in a sandboxed app, thereby extending the latter's sandbox.
To demonstrate the bypass, I've created a sample Xcode project that you can download. The project contains the source code for two apps, a non-sandboxed app and a sandboxed app, the latter of which is embedded within the former. The non-sandboxed app asks you for the path of a file to modify, and the Modify File button opens the file in the sandboxed helper app. The sandboxed helper is a document-based app that overwrites the file's contents (in this case, replacing them with the current date as a string) and saves the file. On macOS 13.5.1, the sample app completely bypasses App Management. I typically test with my open source notarized app Bonjeff. Any file within the Bonjeff bundle can be modified in this way, including the main executable Bonjeff.app/Contents/MacOS/Bonjeff, though I typically test with the license file Bonjeff.app/Contents/Resources/LICENSE.txt to leave the app launchable. The straightforwardness and ease of the bypass is truly stunning.
This isn't the first time that a major macOS update included a new security (theater) feature with a gaping hole. For example, I previously discovered a bypass for Mojave's new privacy protections. And it's important to keep in mind that I'm not a professional security researcher. I'm just a longtime Mac developer, so I happen to know a lot about how the Mac works. Perhaps Apple could use more people like me? I don't mean me specifically, since I'm probably too irascible and obstreperous for a corporate gig, as you can tell by this very blog post.
I've written a follow-up post macOS App Management vulnerability illustrated that attempts to explain the vulnerability in a way that's less technical and friendlier to non-developers.
To clarify, the fact that the /Applications folder is in the sandbox is not the cause of the vulnerability. The issue is much more complicated than that.