8 ms·

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 c

by chias 6y 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 6y ago
Maybe explaining to the user the implications of controlling TextEdit? How scope is expanding? Just thinking out loud here.
- saagarjha 6y ago
  I mean, it does alert you of the consequences when you grant it Apple Events access.
  - scotth 6y 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 6y 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 ¯\_(ツ)_/¯)
      - scotth 6y ago
        Why not list the entitlements, outright? They might not mean anything to most, but the one's that do understand can raise the alarm.
robenkleene 6y ago
My takeaway 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 6y ago
  > 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.
  - robenkleene 6y ago
    To me, that's the absolute worst possible outcome: All of the important software use cases become owned by the existing players forever, because no other competitor can gain traction without Apple's marketing help by being in the App Store, but then they can't become powerful enough to truly compete with the big players by being outside the sandbox. That's exactly what happened with Pixelmator, and it's happening now with the Affinity Suite. Before the sandbox, Pixelmator looked like it would one day be a real Photoshop competitor, but now they're mainly for people who don't want to pay for Adobe's subscription. And, the real Adobe competitors are more likely to come from somewhere else, like the web with Figma. The funny thing is that now Figma is usable on an iPad, because it's a web app, and Sketch, which is an all-Apple technology AppKit app, isn't. Because web apps can avoid the sandbox, even on iOS. Some of the biggest beneficiaries of Apple's security strategy are poised to be some of the apps least invested in Apple's platforms.
    - bitwize 6y ago
bambataa 6y ago
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?
TimTheTinker 6y ago
> I'm curious what the author things a good resolution for this would be. Files created by an app (app1) that is being controlled by another app (app2) should inherit the security context of app2, not app1 (or better yet, where privileges differ, apply the lesser of the the two). The fix should be applied where the security characteristics of a file are written. Perhaps that would mean introducing a new primitive that tracks when an app is being controlled by another app -- not sure. Also, perhaps have special exceptions for files written to places like /Library/Application Support/app1/ -- an app's own working files are unlikely to present privilege escalation opportunities unless app2 is able to exploit a vulnerability in app1. > Also, who would think controlling a text editor is innocuous? I can think of several family members who might think "um why?" but not have any idea of the security implications.
- bredren 6y ago
  > I can think of several family members who might think "um why?" but not have any idea of the security implications. This is definitely the case. When presented with a dialog that prevents progression, many, many users will click whatever makes it "go away." However, when I see something like this, I get the heebie-jeebies. Apple's done a great job at locking down stuff, and when I have to provide accessibility or some other weirdness I know what I'm doing. I think if a successful exploit of this started spreading, Apple might add some exception for TextEdit. But in lieu of that, I can only imagine the amount of substantial, unprompted security problems are quite extensive.
closeparen 6y ago
This class of problem is interesting and well-known because it doesn't have a great resolution within the most popular access control schemes. https://en.wikipedia.org/wiki/Confused_deputy_problem https://en.wikipedia.org/wiki/Confused_deputy_problem
kevingadd 6y ago
Tricking a higher-privileged bit of code into doing the bidding of a lower-privileged app is really common in the history of nasty security exploits. Windows Kernel developers and Web Browser developers have both spent over a decade systematically eliminating scenarios where this can happen, whether it's forging WM_TIMER messages or attempting to get around javascript API origin/trust restrictions. "I convinced this other program to dump an executable shell script onto disk for me so I could run it without a prompt" is a textbook escalation of privilege vulnerability, and being able to do it with a common app like TextEdit or BBEdit is pretty serious. One solution is for the outermost caller's credentials to apply all the way down the chain. This is common in Windows and in web browsers - web browsers basically track whether the current chain of actions originated from user input or not so that they can prevent websites from silently doing nasty stuff without user consent. At this point browsers actually track that consent data across asynchronous computation so everything will work. I personally don't think an app with 'create shell script' permissions should be able to be controlled by Joe's Random Unprivileged App, but that's just me. Windows certainly doesn't allow low integrity apps to communicate with arbitrary high integrity apps. Introducing that restriction is an essential security improvement.

by chias 6y ago

scotth 6y ago

Maybe explaining to the user the implications of controlling TextEdit? How scope is expanding? Just thinking out loud here.

saagarjha 6y ago
I mean, it does alert you of the consequences when you grant it Apple Events access.
- scotth 6y 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 6y 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 ¯\_(ツ)_/¯)
    - scotth 6y ago
      Why not list the entitlements, outright? They might not mean anything to most, but the one's that do understand can raise the alarm.

robenkleene 6y ago

My takeaway 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 6y ago
> 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.
- robenkleene 6y ago
  To me, that's the absolute worst possible outcome: All of the important software use cases become owned by the existing players forever, because no other competitor can gain traction without Apple's marketing help by being in the App Store, but then they can't become powerful enough to truly compete with the big players by being outside the sandbox. That's exactly what happened with Pixelmator, and it's happening now with the Affinity Suite. Before the sandbox, Pixelmator looked like it would one day be a real Photoshop competitor, but now they're mainly for people who don't want to pay for Adobe's subscription. And, the real Adobe competitors are more likely to come from somewhere else, like the web with Figma. The funny thing is that now Figma is usable on an iPad, because it's a web app, and Sketch, which is an all-Apple technology AppKit app, isn't. Because web apps can avoid the sandbox, even on iOS. Some of the biggest beneficiaries of Apple's security strategy are poised to be some of the apps least invested in Apple's platforms.
  - bitwize 6y ago

bambataa 6y ago

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?

TimTheTinker 6y ago

> I'm curious what the author things a good resolution for this would be. Files created by an app (app1) that is being controlled by another app (app2) should inherit the security context of app2, not app1 (or better yet, where privileges differ, apply the lesser of the the two). The fix should be applied where the security characteristics of a file are written. Perhaps that would mean introducing a new primitive that tracks when an app is being controlled by another app -- not sure. Also, perhaps have special exceptions for files written to places like /Library/Application Support/app1/ -- an app's own working files are unlikely to present privilege escalation opportunities unless app2 is able to exploit a vulnerability in app1. > Also, who would think controlling a text editor is innocuous? I can think of several family members who might think "um why?" but not have any idea of the security implications.

bredren 6y ago
> I can think of several family members who might think "um why?" but not have any idea of the security implications. This is definitely the case. When presented with a dialog that prevents progression, many, many users will click whatever makes it "go away." However, when I see something like this, I get the heebie-jeebies. Apple's done a great job at locking down stuff, and when I have to provide accessibility or some other weirdness I know what I'm doing. I think if a successful exploit of this started spreading, Apple might add some exception for TextEdit. But in lieu of that, I can only imagine the amount of substantial, unprompted security problems are quite extensive.

closeparen 6y ago

This class of problem is interesting and well-known because it doesn't have a great resolution within the most popular access control schemes. https://en.wikipedia.org/wiki/Confused_deputy_problem https://en.wikipedia.org/wiki/Confused_deputy_problem

kevingadd 6y ago

Tricking a higher-privileged bit of code into doing the bidding of a lower-privileged app is really common in the history of nasty security exploits. Windows Kernel developers and Web Browser developers have both spent over a decade systematically eliminating scenarios where this can happen, whether it's forging WM_TIMER messages or attempting to get around javascript API origin/trust restrictions. "I convinced this other program to dump an executable shell script onto disk for me so I could run it without a prompt" is a textbook escalation of privilege vulnerability, and being able to do it with a common app like TextEdit or BBEdit is pretty serious. One solution is for the outermost caller's credentials to apply all the way down the chain. This is common in Windows and in web browsers - web browsers basically track whether the current chain of actions originated from user input or not so that they can prevent websites from silently doing nasty stuff without user consent. At this point browsers actually track that consent data across asynchronous computation so everything will work. I personally don't think an app with 'create shell script' permissions should be able to be controlled by Joe's Random Unprivileged App, but that's just me. Windows certainly doesn't allow low integrity apps to communicate with arbitrary high integrity apps. Introducing that restriction is an essential security improvement.