Articles index

Mac sandbox escape

April 27 2020 by Jeff Johnson
Support this blog: Link Unshortener, StopTheMadness, Underpass, PayPal.Me

This blog post discloses a sandbox escape on macOS. I reported the issue to Apple Product Security on December 19 2019, the day the Apple Security Bounty program finally opened. (I discovered the issue in August 2019.) Today I received an email from Apple Product Security saying "we do not see any actual security implications." I've heard this kind of response before — they don't see any security implications… until they do — but in any case I obviously won't be receiving a bounty for this issue, and I'm free to publish it, again letting the public judge for themselves whether there are security implications. To save myself time, I'm just going to copy and paste my original report:

Attached is a sample Xcode project that demonstrates how a sandboxed Mac app can escape the sandbox with one click. This sandbox escape works on the current public shipping version macOS 10.15.2. I've also tested on macOS 10.14.6.

To reproduce, build and run the sample app. Then click to allow when the system dialog asks if the sample app can control TextEdit via Apple Events. This will allow the sample app to create a file named "escaped" in the directory "/Users/Shared", outside the sandbox. You'll also hear the app say "hi" to signal that it's successfully escaped the sandbox. The sample app has actually launched a shell script, "test.sh", which can run any arbitrary code outside the sandbox.

The sandbox escape is made possible by the entitlement "com.apple.security.files.user-selected.executable" possessed by TextEdit. It's also possessed by some Mac App Store apps such as BBEdit. (Note that while TextEdit and BBEdit are themselves sandboxed, this entitlement would also allow them to escape their own sandbox. Thus, any app with the "com.apple.security.files.user-selected.executable" entitlement is only nominally sandboxed, effectively not sandboxed.)

Normally, when a sandboxed app writes to a file, the file is quarantined. If the file is a shell script, then the quarantine extended attribute would prevent the script from running. However, when an app such as TextEdit with the "com.apple.security.files.user-selected.executable" entitlement saves a file, it removes the quarantine extended attribute!

My sample app opens a shell script in TextEdit, and then it uses the Apple Events permission to tell TextEdit to save the file, thus removing the quarantine and allowing the script to be executed outside the app's sandbox.

This should appear very innocuous to the user, because nobody thinks that TextEdit is dangerous, so one would think it's not much of a risk to allow TextEdit to be controlled.

SandboxEscape.zip

Note that I chose the directory /Users/Shared to avoid macOS "privacy protections" that prevent interaction with various other directories such as Desktop, Documents, and Downloads. Note also that this issue (if you consider it an issue) still exists on the latest version 10.15.4 of macOS.

Update on April 30 2020

I've written a new blog post that attempts to clarify a number of issues raised here.

Support this blog: Link Unshortener, StopTheMadness, Underpass, PayPal.Me

Articles index