9 ms·

Mac sandbox escape

188 points by miles 7y ago

rgovostes 7y ago
The key part seems to be this: > Then click to allow when the system dialog asks if the sample app can control TextEdit via Apple Events. The author argues, > 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. This is what the dialog looks like: https://imgur.com/a/HRXDG0x https://imgur.com/a/HRXDG0x The smaller text is where the app developer provides an explanation for why they are requesting the permission.
- SalimoS 7y ago
  And to explain his argument he explained > 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!
chrisseaton 7y ago
> Then click to allow when the system dialog asks if the sample app can control TextEdit via Apple Events. Seems to require the user to explicitly give the application permission to escape the sandbox?
- rileymat2 7y ago
  I work on the platform all day, and I would not put that together as obviously dangerous.
- peterbmarks 7y ago
  The author is right that controlling TextEdit seems harmless. It could be done in the context of showing the user release notes or something. AppleEvents must be a nightmare for Apple's security auditors.
  - rgovostes 7y ago
    You can tell another app to open a document without having permissions to send arbitrary Apple Events (which effectively let you act as a user interacting with the app). Even if TextEdit files were quarantined so you could not execute them, you would still be able to do harm, such as snooping on the user's recent documents, or trashing the disk by overwriting files that TextEdit has access to. Likely it could even install a LaunchAgent to run arbitrary code outside of the sandbox as well. There's already a security dialog here that warns the user. Maybe the user's imagination doesn't run wild with all the ways that the access could be abused, but they _were_ warned.
diebeforei485 7y ago
The latest version of Zoom (released yesterday) also has the entitlement to send Events to other applications. It's unclear why it requires this entitlement. Anyone know? [>] codesign -d --entitlements :- /Applications/zoom.us.app ... <key>com.apple.security.automation.apple-events</key> <true/>
- samuelg123 7y ago
  I believe there’s a feature that allows others to take control of the screen. It could be related to this
  - btilly 7y ago
    I had the same thought, but that feature is https://support.zoom.us/hc/en-us/articles/201362673-Request-or-Give-Remote-Control https://support.zoom.us/hc/en-us/articles/201362673-Request-... and needs permissions under Accessibility.
    - judge2020 7y ago
      Maybe they also intend to allow controlling single applications at some point.
- givinguflac 7y ago
  I would imagine it’s used for scheduling meetings in other apps.
  - lonelappde 7y ago
    Which is horrific. It should export an event/intent for the user to to route.
- bkdbkd 7y ago
  iirc remote mouse & keyboard control was added recently.
Twisell 7y ago
I just don't known what to make of OP last sentence : > 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. If the script can't access protected locations did it actually break the sandbox? Can you actually run the file in /Users/Shared scripts afterward and access those locations from there on? On Catalina the shell is kinda sandboxed when run interactively, does this exploit bypass by tuning as TextEdit?
- mike_d 7y ago
  There is a bit of confusion because macOS has two sandboxes: app store app isolation and permissions and file system isolation. Think of the latter as everything on the file system except /Users and a few other cherry picked directories being mounted from a read-only CD-ROM.
  - saagarjha 7y ago
    The latter usually goes by the name "Data Vaults" and actually extends to a blacklist of directories (and at a technical level is enforced in a different manner). Things like ~/Documents, ~/Downloads and ~/Desktop are inaccessible to applications without permission.
chias 7y ago
Putting on the other hat for a minute, I'm curious what the author things a good resolution for this would be. Perhaps that any time you use a text editor to create, edit, or save a shell script, that script should be treated as a freshly downloaded and untrusted script? Or that it should be impossible to control a text editor from another application, even when given explicit permission from the operator? Both of those sound awful. Is there a third option I'm missing here? I'm with Apple on this one. ----- Also, who would think controlling a text editor is innocuous? A text editor's modus operandi is literally to create, read, update, or delete any file to which your user has access.
- scotth 7y ago
  Maybe explaining to the user the implications of controlling TextEdit? How scope is expanding? Just thinking out loud here.
  - saagarjha 7y ago
    I mean, it does alert you of the consequences when you grant it Apple Events access.
    - scotth 7y ago
      Sure. I was thinking more along the lines of a mobile OS, where you're given some insight as to what the app is actually asking for. Which I think overall is a good thing...although the granularity or function of the permissions you can request here might not be as easy to understand. (Not sure why I'm being downvoted above)
      - saagarjha 7y ago
        It does give you a similar alert as it would on iOS; the issue with Apple Events is that it generally gives you the same permissions as the process that you're controlling so it's fairly hard to describe it in general. This isn't an issue on iOS because such a permission doesn't really exist. (I can't explain the downvotes, either. Hacker News is fickle ¯\_(ツ)_/¯)
droopyEyelids 7y ago
This is cool because it shows Apple built a castle on a foundation of sand. The author points to the sand, and Apple says "we're only interested in the castle." In one sense, to agree with most of the comments here, thats the practical answer for Apple! Show us the problem with what we've built! In another sense, I scooped the sand away from the foundation of your castle, and now I'm inside.
fouc 7y ago
I'm not sure this is necessarily a security issue, it is perhaps more of a social engineering issue. The user IS shown a suspicious dialogue "App wants access to control TextEdit". What apple could do is perhaps add some sort of indication or extra step to help users make the informed choice.
- Operyl 7y ago
  You have the problem that too much information will just get skipped over by the user too. It has to be the right length of text if you want to try and get them to read it.
greggman3 7y ago
Just the ability to access the rest of the file system I think I wish was on a folder by folder basis. My text editor for example, I personally wouldn't mind if once per project I had to give it permission to access a project's folder. I also wish there was a way to edit a file without giving access to the folder. For example Photoshop, I can select from the finder "Open In Photoshop" which is enough intent to give the app permission to access that file without having to give it access to the other files in the same folder. I get that would require API changes and that Apple doing that overnight would break apps but basically going forward I wish OS makers would work toward something like that. Even on iPhone I hate that apps either get permission to read all photos or none. Yes I get you can send a photo to an app but many apps can not receive them for every use. I get the apps want to present their own UI for the photos. Maybe some kind of OS run sandboxed process where the app can provide a limited function to present thumbnails but can't actually read any data and all they get out of that process from the OS is the user selected files? Oh well, I can dream.
- ddrt 7y ago
  Completely agree and you put this perfectly.
- szc 7y ago
  The problem is not the viewing, but editing. When you say "Open In Photoshop" does this mean you can make changes and then save the "file"? What if Photoshop doesn't just "save" a file, but writes several intermediate files onto the filesystem and does a bunch of file renames to create a "backup" of the original image. Those operations are no longer just operating on a single file any more. From the perspective of a security system implementor, how can you understand such intent from sequences of raw POSIX filesystem calls -- because that is all the sandbox enforcement code in the OS kernel gets to see and approve or deny. For code that uses Apple's Cocoa frameworks, when you ask at a high level to work on a file (or a bundle) a "Powerbox" is used -- it runs out of process and hands back the App permission to make modifications to that file (or bundle) based on the way Cocoa manipulates objects. If the app doesn't use Cocoa, the best that can be done is delegate permission to a directory. The iPhone allowed a different security model to be created as there was no direct access to "files" and "folders". There were and still are problematic APIs that are based on a give me full access or nothing model. It is quite a challenge to retrofit a security model onto something that ultimately doesn't break something major in an unexpected way.
moonchild 7y ago
It looks like the core problem here is not that the TextEdit entitlement gives arbitrary code execution, but rather that sandboxing is not transitive. If application X has its actions restricted in some way, it should not be able to bypass that by running application Y, for any Y.
dathinab 7y ago
Is it just me or is the MacOS security often not fully thought through. I mean this isn't the first vulnerabilities of it's kind.

188 points by miles 7y ago

The key part seems to be this: > Then click to allow when the system dialog asks if the sample app can control TextEdit via Apple Events. The author argues, > 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. This is what the dialog looks like: https://imgur.com/a/HRXDG0x https://imgur.com/a/HRXDG0x The smaller text is where the app developer provides an explanation for why they are requesting the permission.

SalimoS 7y ago
And to explain his argument he explained > 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!

chrisseaton 7y ago

> Then click to allow when the system dialog asks if the sample app can control TextEdit via Apple Events. Seems to require the user to explicitly give the application permission to escape the sandbox?

rileymat2 7y ago
I work on the platform all day, and I would not put that together as obviously dangerous.
peterbmarks 7y ago
The author is right that controlling TextEdit seems harmless. It could be done in the context of showing the user release notes or something. AppleEvents must be a nightmare for Apple's security auditors.
- rgovostes 7y ago
  You can tell another app to open a document without having permissions to send arbitrary Apple Events (which effectively let you act as a user interacting with the app). Even if TextEdit files were quarantined so you could not execute them, you would still be able to do harm, such as snooping on the user's recent documents, or trashing the disk by overwriting files that TextEdit has access to. Likely it could even install a LaunchAgent to run arbitrary code outside of the sandbox as well. There's already a security dialog here that warns the user. Maybe the user's imagination doesn't run wild with all the ways that the access could be abused, but they _were_ warned.

diebeforei485 7y ago

The latest version of Zoom (released yesterday) also has the entitlement to send Events to other applications. It's unclear why it requires this entitlement. Anyone know? [>] codesign -d --entitlements :- /Applications/zoom.us.app ... <key>com.apple.security.automation.apple-events</key> <true/>

samuelg123 7y ago
I believe there’s a feature that allows others to take control of the screen. It could be related to this
- btilly 7y ago
  I had the same thought, but that feature is https://support.zoom.us/hc/en-us/articles/201362673-Request-or-Give-Remote-Control https://support.zoom.us/hc/en-us/articles/201362673-Request-... and needs permissions under Accessibility.
  - judge2020 7y ago
    Maybe they also intend to allow controlling single applications at some point.
givinguflac 7y ago
I would imagine it’s used for scheduling meetings in other apps.
- lonelappde 7y ago
  Which is horrific. It should export an event/intent for the user to to route.
bkdbkd 7y ago
iirc remote mouse & keyboard control was added recently.

Twisell 7y ago

I just don't known what to make of OP last sentence : > 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. If the script can't access protected locations did it actually break the sandbox? Can you actually run the file in /Users/Shared scripts afterward and access those locations from there on? On Catalina the shell is kinda sandboxed when run interactively, does this exploit bypass by tuning as TextEdit?

mike_d 7y ago
There is a bit of confusion because macOS has two sandboxes: app store app isolation and permissions and file system isolation. Think of the latter as everything on the file system except /Users and a few other cherry picked directories being mounted from a read-only CD-ROM.
- saagarjha 7y ago
  The latter usually goes by the name "Data Vaults" and actually extends to a blacklist of directories (and at a technical level is enforced in a different manner). Things like ~/Documents, ~/Downloads and ~/Desktop are inaccessible to applications without permission.

chias 7y ago

Putting on the other hat for a minute, I'm curious what the author things a good resolution for this would be. Perhaps that any time you use a text editor to create, edit, or save a shell script, that script should be treated as a freshly downloaded and untrusted script? Or that it should be impossible to control a text editor from another application, even when given explicit permission from the operator? Both of those sound awful. Is there a third option I'm missing here? I'm with Apple on this one. ----- Also, who would think controlling a text editor is innocuous? A text editor's modus operandi is literally to create, read, update, or delete any file to which your user has access.

scotth 7y ago
Maybe explaining to the user the implications of controlling TextEdit? How scope is expanding? Just thinking out loud here.
- saagarjha 7y ago
  I mean, it does alert you of the consequences when you grant it Apple Events access.
  - scotth 7y ago
    Sure. I was thinking more along the lines of a mobile OS, where you're given some insight as to what the app is actually asking for. Which I think overall is a good thing...although the granularity or function of the permissions you can request here might not be as easy to understand. (Not sure why I'm being downvoted above)
    - saagarjha 7y ago
      It does give you a similar alert as it would on iOS; the issue with Apple Events is that it generally gives you the same permissions as the process that you're controlling so it's fairly hard to describe it in general. This isn't an issue on iOS because such a permission doesn't really exist. (I can't explain the downvotes, either. Hacker News is fickle ¯\_(ツ)_/¯)

droopyEyelids 7y ago

This is cool because it shows Apple built a castle on a foundation of sand. The author points to the sand, and Apple says "we're only interested in the castle." In one sense, to agree with most of the comments here, thats the practical answer for Apple! Show us the problem with what we've built! In another sense, I scooped the sand away from the foundation of your castle, and now I'm inside.

fouc 7y ago

I'm not sure this is necessarily a security issue, it is perhaps more of a social engineering issue. The user IS shown a suspicious dialogue "App wants access to control TextEdit". What apple could do is perhaps add some sort of indication or extra step to help users make the informed choice.

Operyl 7y ago
You have the problem that too much information will just get skipped over by the user too. It has to be the right length of text if you want to try and get them to read it.

greggman3 7y ago

Just the ability to access the rest of the file system I think I wish was on a folder by folder basis. My text editor for example, I personally wouldn't mind if once per project I had to give it permission to access a project's folder. I also wish there was a way to edit a file without giving access to the folder. For example Photoshop, I can select from the finder "Open In Photoshop" which is enough intent to give the app permission to access that file without having to give it access to the other files in the same folder. I get that would require API changes and that Apple doing that overnight would break apps but basically going forward I wish OS makers would work toward something like that. Even on iPhone I hate that apps either get permission to read all photos or none. Yes I get you can send a photo to an app but many apps can not receive them for every use. I get the apps want to present their own UI for the photos. Maybe some kind of OS run sandboxed process where the app can provide a limited function to present thumbnails but can't actually read any data and all they get out of that process from the OS is the user selected files? Oh well, I can dream.

ddrt 7y ago
Completely agree and you put this perfectly.
szc 7y ago
The problem is not the viewing, but editing. When you say "Open In Photoshop" does this mean you can make changes and then save the "file"? What if Photoshop doesn't just "save" a file, but writes several intermediate files onto the filesystem and does a bunch of file renames to create a "backup" of the original image. Those operations are no longer just operating on a single file any more. From the perspective of a security system implementor, how can you understand such intent from sequences of raw POSIX filesystem calls -- because that is all the sandbox enforcement code in the OS kernel gets to see and approve or deny. For code that uses Apple's Cocoa frameworks, when you ask at a high level to work on a file (or a bundle) a "Powerbox" is used -- it runs out of process and hands back the App permission to make modifications to that file (or bundle) based on the way Cocoa manipulates objects. If the app doesn't use Cocoa, the best that can be done is delegate permission to a directory. The iPhone allowed a different security model to be created as there was no direct access to "files" and "folders". There were and still are problematic APIs that are based on a give me full access or nothing model. It is quite a challenge to retrofit a security model onto something that ultimately doesn't break something major in an unexpected way.

moonchild 7y ago

It looks like the core problem here is not that the TextEdit entitlement gives arbitrary code execution, but rather that sandboxing is not transitive. If application X has its actions restricted in some way, it should not be able to bypass that by running application Y, for any Y.

dathinab 7y ago

Is it just me or is the MacOS security often not fully thought through. I mean this isn't the first vulnerabilities of it's kind.