• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: A wild OS X security hole appears!!!! [Was: Application library ?]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A wild OS X security hole appears!!!! [Was: Application library ?]


  • Subject: Re: A wild OS X security hole appears!!!! [Was: Application library ?]
  • From: has <email@hidden>
  • Date: Thu, 14 Jan 2016 00:18:05 +0000

Shane Stanley wrote:
> 
> On 6 Jan 2016, at 4:35 AM, has wrote:
>> 
>> OK, so before I Radar the following wharrgarbl as a Major Security Hole, can someone else here please *confirm* for me that installing an OS X application named (e.g.) 'Foo.app' containing a script library named 'Bar.scpt[d]' does indeed automatically override an identically named 'Bar.scpt[d]' library in '~/Library/Script Library' whenever a user script subsequently executes a `use script "Bar"` import statement.
> 
> Um, no, that does not happen.
FWIW, the order outlined in the ASLG appears to be incorrect: ~/Library/Script Libraries is checked before app bundles. However, /Library/Script Libraries appears to be checked after app bundles, so let's assume that's what Hamish meant.

Agreed, ASLG describes the search order wrong. (Something I'm sure Chris Page could quickly correct by telling us the exact order in which it does do it.) I still need to sit down and write up a full set of hard test cases to go with the ticket, which I'll aim to do next time I heave the old corpse up the office as I've a clean test box up there.

Armageddon? Hardly. Yes, someone could distribute scripts that do nefarious things. It's been that way for more than 20 years. Automator is open to something similar. 

There's a huge difference between accidental/deliberate mis-behaviors that users *explicitly* initiate, and accidental/deliberate mis-behaviors that initiate themselves. It's the difference between the user intentionally clicking on the .exe attachment at the end of a spam email, and Outlook executing malicious code merely by fetching emails from the mail server [1]. What AppleScript is doing here is an example of the latter: unexpected or malicious code can accidentally/deliberately inject itself without the user doing a thing.

Apps can already use AppleScript to hide malicious code. 

Not if the app is sandboxed and running the malicious code in-process, because the sandbox will stop that code dead.

Whether it's possible for a sandboxed app to execute the malicious script outside of that sandbox

And without a StandardLib it's moot anyway.

It's not "moot"; merely not a vector *currently* worth exploiting. To exploit it the attacker must know - or at least be able to guess - the names of AppleScript libraries that are on the user's system, and have some likelihood that his app will be installed on machines containing those libraries. Right now, there isn't an AppleScript library ecosystem worth shit, so of course no-one's going to bother attacking it, because the chance of a hit is effectively zero. But that changes the moment Apple adds a standard library, because those names will be fixed and permanent, and now anyone who runs an AppleScript for any reason is a potential target.

In other words, this is *exactly* the time to plug the hole; *before* it ever has any chance to become a practical exploit.

Why would someone bother, when they can cause so much more damage, and to a much wider audience, without resort to such an obscure technique?

Gah. This is *exactly* the attitude to security that guarantees TheDailyWTF.com will never, ever run out of hilariously horrific stories to print. Finding, studying, and exploiting 'obscure techniques' is what amateur and professional crackers *do*.

Don't mistake my tongue-in-cheek scenario for the real thing, cos when real attackers get into your machine they won't be nearly so generous as to make it obvious. Instead, they'll scan your files for personal information, attempt to insert a backdoor or two, and then - maybe, if they've nothing better to do, - encrypt a bunch of your files and send you a message telling you to pay up if you ever want to unlock them again. It's all about probabilities: an attack only needs to catch enough users to be profitable, and with many millions of users out there, even a fraction of a percent success rate makes it worth doing.


And why can't the App Store audit this code?

1. I doubt there's anyone at Apple who can read AppleScript code well enough to identify all possible nasties, never mind automate the process. 2. You're assuming he/she/it would, or even could, reliably detect all potential issues. (Hint: if the AppStore auditing process was guaranteed to catch 100% of naughtiness in apps, OS X wouldn't need to run them in sandboxes!)


Personally, the existence of "do shell script ... with administrator privileges" makes me lose more sleep.

No big disagreement there, since anything that inculcates in users the habit of entering admin logins into every dialog they see is really not the best way to develop good security practices amongst said users. Still, even that boils down to "My User Made Me Do It", which is leagues away from "I Did It All By Myself". We may grant the machine a degree of leeway on the former, as we've yet to invent a machine that is always smarter than users can be dumb, but the latter has no such excuse. Developers who write insecure software have absolutely no business being software developers, and the sooner they and their crapware are patched out of existence the better.


> 1. I downloaded a copy of Apple Configurator, and ran `tell script "Configuration Utility" to CNFGgetUtilityPath()` in Script Editor, which promptly returned "/Applications/Apple Configurator 2.app/Contents/MacOS/cfgutil". That alone is significant hole, and needs a security ticket filed on it.
So log it. I can't see that it tells you anything you can't figure out other ways, like using path to application... and concatenating, so it strikes me as completely academic -- but whatever.

Sorry, that was unclear. It's the 'tell script "Configuration Utility"...end tell' statement that is the security hole, not any particular command within it. I just picked CNFGgetUtilityPath() at random to prove the library was loaded and working; its result is not important, only the fact that it was callable without further qualification.


A runtime's dynamic search paths should *only* be added, modified, or removed upon *explicit* instruction by the system administrator or current user, and those changes should not be visible outside of the scope in which they were made. 
The use of /Library inside app bundles is an established practice. QuickLook, Spotlight and Automator use it. Nothing new in that.

The difference is that 1. a bundled QuickLook/Spotlight plugin should always execute inside a sandbox to ensure it can't do anything outside of its intended role, while 2. a bundled Automator plugin (which can't be sandboxed for obvious reasons) should always have a unique identifier to ensure it can *never* accidentally/deliberately mask or be confused for another Automator plugin, so will only be run when a user *explicitly* tells it to run.

Like I say, it would be fine having a 'Script Libraries' folder within an application bundle, *as long as* the 'tell' block *must* explicitly declare the application. i.e. This is safe code:

    tell script "Configuration Utility" of application "Apple Configurator"
        -- do stuff
    end tell

But this (the current implementation) is not:

    tell script "Configuration Utility"
        -- do stuff
    end tell

As an added bonus, eliminating the second (current) form *drastically* reduces the number of folders that AppleScript's library loader has to scan when looking for libraries. I suspect the only reason the current caching behavior was devised is because of the need to scan many dozens (if not hundreds) of installed applications, on top of the half-dozen or so standard and user-defined 'Script Libraries' locations. But it makes testing and debugging libraries a pain, while providing zero actual benefit in various common use cases where a script loads, runs once, and quits (e.g. SE applets, NSUserAppleScriptTask, osascript).

Take a look at the `python` and `ruby` interpreters: these habitually run-once-and-quit, yet they start up quickly enough each time without any such caching. If they can do it, AppleScript should be able to do it too. Fix the security hole aspect of arbitrary-search-path-injection, and the stale cache problem can be eliminated too, because with only a small number of known Script Libraries folders they can just be rescanned every time a user script is run, and the cache refreshed when changes are detected. (OK, there's a few extra details to hammer out regarding persistent scripts, but it's still not rocket science.) As I've no doubt said before, it's amazing how many problems can be avoided simply by developers not creating them in the first place.


Anyway, apologies for the slow response, but it's not just the country that's under the weather this month. (Not that I'm terribly prompt even at best of times.:p)

Regards,

has


[1] Random example: http://www.computerworld.com/article/2596009/networking/update--microsoft-scrambling-to-fix-new-outlook-security-hole.html


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users

This email sent to email@hidden

  • Follow-Ups:
    • Re: A wild OS X security hole appears!!!! [Was: Application library ?]
      • From: Shane Stanley <email@hidden>
  • Prev by Date: Re: Grammar Police in OS X 10.11
  • Next by Date: Re: A wild OS X security hole appears!!!! [Was: Application library ?]
  • Previous by thread: Script Library caching
  • Next by thread: Re: A wild OS X security hole appears!!!! [Was: Application library ?]
  • Index(es):
    • Date
    • Thread