[HN Gopher] Mac Sandbox Escape
___________________________________________________________________
Mac Sandbox Escape
Author : miles
Score : 51 points
Date : 2020-04-29 20:41 UTC (2 hours ago)
(HTM) web link (lapcatsoftware.com)
(TXT) w3m dump (lapcatsoftware.com)
| diebeforei485 wrote:
| 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 wrote:
| I believe there's a feature that allows others to take control
| of the screen. It could be related to this
| btilly wrote:
| I had the same thought, but that feature is
| https://support.zoom.us/hc/en-
| us/articles/201362673-Request-... and needs permissions under
| Accessibility.
| chias wrote:
| 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 wrote:
| Maybe explaining to the user the implications of controlling
| TextEdit? How scope is expanding? Just thinking out loud here.
| saagarjha wrote:
| I mean, it does alert you of the consequences when you grant
| it Apple Events access.
| robenkleene wrote:
| My take away is more that the entire security model that Apple
| is pushing for the Mac just doesn't really make sense. E.g.,
| here's a quick list of apps that aren't sandboxed: Logic Pro,
| Final Cut, most of Adobe Creative Cloud, Visual Studio
| Code/Atom/TextMate, Xcode, and Sketch. If I were to make a list
| of the main apps people buy Macs to run, it's pretty much the
| same list.
|
| The particular case highlighted in the blog post is specific to
| code editors, but similar types of problems arise in all of the
| most important app categories for Macs.
| mike_d wrote:
| > If I were to make a list of the main apps people buy Macs
| to run, it's pretty much the same list.
|
| That is exactly the point. The apps you listed are used in
| tons of corporate environments and fairly well vetted,
| usually with bug bounty programs or full time security teams
| backing them. It's the smaller one-off apps that people
| aren't putting eyes on regularly that get sandboxed.
| muricula wrote:
| This issue goes beyond MacOS too. The traditional model of
| allowing any process to read and write anything created by
| the same user, send IPC messages (unix sockets, mach ports,
| window messages etc.) to most processes, and execute any
| subprocess has serious security and privacy implications.
| iOS, Android, and to a lesser extent ChromeOS offer a
| different, more intuitive, security model, but one which is
| difficult to retrofit to traditional OSs.
|
| Attempts to retrofit a sandbox to older OSs are full of
| holes, and it's interesting to see how different ecosystems
| attempt to do this, with containers, AppArmor, the seatbelt
| sandbox, and other things brewing in Redmond.
| bambataa wrote:
| Judging by the entitlements, it seems that a script can save an
| executable file. Would it be possible to ensure that any file
| written by a script remains quarantined?
| rgovostes wrote:
| 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
|
| The smaller text is where the app developer provides an
| explanation for why they are requesting the permission.
| SalimoS wrote:
| 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 wrote:
| > 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 wrote:
| I work on the platform all day, and I would not put that
| together as obviously dangerous.
| peterbmarks wrote:
| 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 wrote:
| 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.
| Twisell wrote:
| 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 wrote:
| 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 wrote:
| The latter usually goes by the name "Data Vaults" and
| actually extends to a blacklist of directories. Things like
| ~/Documents, ~/Downloads and ~/Desktop are inaccessible to
| applications without permission.
___________________________________________________________________
(page generated 2020-04-29 23:00 UTC)