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
|