Jeff Johnson (My apps, PayPal.Me, Mastodon)

macOS App Management vulnerability illustrated

August 20 2023

Yesterday I disclosed an unfixed security vulnerability in macOS Ventura's App Management protection. The explanation was fairly technical, and you had to use Apple's Xcode developer tool in order to test the vulnerability yourself with my sample app. Today I want to illustrate the vulnerability a little more clearly to a non-developer audience. (For more background reading on App Management, see my blog post How macOS Ventura App Management works and doesn't work from last year.)

App Management, newly introduced in macOS Ventura, protects notarized apps from unauthorized modification. A notarized app has been checked by Apple for malware, and macOS Gatekeeper tells you upon first launching the app that it has been checked by Apple for malware. Once you've installed a notarized app on your Mac, the app should remain free of malware, as long as it's not modified. However, an attacker who can modify one of the apps installed on your Mac could use the capabilities of that app to do nasty things. For the purpose of illustration, I've chosen a popular notarized app that many Mac users might have installed: Firefox.

Specifically, I'm going to try to modify the file /Applications/Firefox.app/Contents/Resources/update-settings.ini inside the Firefox app bundle. Here are the normal contents of the file:

; If you modify this file updates may fail.
; Do not modify this file.

[Settings]
ACCEPTED_MAR_CHANNEL_IDS=firefox-mozilla-release

As you can see, modifying that file would mess with Firefox's software update mechanism, perhaps leaving the user vulnerable to a malicious software update.

First I'm going to try to modify the file from Terminal (/System/Applications/Utilities/Terminal.app). If you're following along with me, make sure that Terminal does not have Full Disk Access, because as I explained in my App Management blog post last year, Full Disk Access automatically grants the ability to bypass App Management.

System Settings, Full Disk Access

Now I open Terminal and attempt to overwrite the contents of the Firefox file with "PWNED!"

As expected, that doesn't work.

zsh: operation not permitted: /Applications/Firefox.app/Contents/Resources/update-settings.ini

In this case, App Management has protected Firefox from unauthorized modification.

Terminal.app was prevented from modifying apps on your Mac.

And we see in System Settings that Terminal does not have App Management permissions.

System Settings, App Management

Now I open the Firefox file in TextEdit.

open -a TextEdit /Applications/Firefox.app/Contents/Resources/update-settings.ini

I edit the file, again attempting to replace the contents with "PWNED!"

TextEdit edited

I save the file in TextEdit, and… it works?

TextEdit saved

I can verify in Terminal that the file contents have indeed been successfully modified.

cat /Applications/Firefox.app/Contents/Resources/update-settings.ini

This time there was no App Management system alert, and the file modification was not prevented. Why?

TextEdit is sandboxed. Ironically, sandboxing was designed to prevent attacks, but in this case it allows an attack. That's the bug, the vulnerability. A sandboxed app can modify a file that is supposed to be protected by App Management.

This has all been just for illustration. It wasn't a real, viable attack, because I had to do everything manually. However, my disclosure yesterday presented an example of an automated tool that could execute a real attack. My tool was actually two apps in one: a "maliciously crafted" non-sandboxed app that has access to any files that need attacking and a "maliciously crafted" sandboxed app embedded inside the non-sandboxed app. The non-sandboxed app tells the sandboxed app to open the file, just as I told Terminal, a non-sandboxed app, to open Firefox's file in TextEdit, a sandboxed app. My maliciously crafted sandboxed app modifies the file and saves it, just as I manually modified the Firefox file and saved it in TextEdit. The only difference between the two scenarios is that a real attack happens automatically, while my illustration all happened manually.

I know that this can be confusing, because there are three different apps involved. Don't forget that the ultimate goal of the attack is to modify a notarized app already installed on your Mac, such as Firefox. The other two apps, the combination of the non-sandboxed app and the sandboxed app (such as Terminal and TextEdit) are the tools that are used by the attacker to make an unauthorized modification to the notarized app. My vulnerability report to Apple showed that if you download and run a maliciously crafted app from the internet, then it is capable of bypassing Ventura App Management and modifying the other notarized apps on your Mac.

Addendum August 22 2023

It's crucial to recognize that in my illustration of the vulnerability, there's no utilization of the open panel in TextEdit, no drag and drop, no user gesture that would convey special permissions. I use the open command in Terminal app, which could be run as easily by a shell script as by a person typing, and my sample Xcode project uses the API -[NSWorkspace openURLs: withApplicationAtURL: configuration: completionHandler], which also requires no user intervention and can be called silently by a maliciously crafted app.

Jeff Johnson (My apps, PayPal.Me, Mastodon)