Re: A wild OS X security hole appears!!!! [Was: Application library ?]
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: Wed, 06 Jan 2016 01:31:32 +0000
On 05/01/2016 22:57, Shane Stanley wrote:
On 6 Jan 2016, at 4:35 AM, has <email@hidden> 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.
Next...
Uh, details? It's actually damned difficult figuring exactly what's
going on here because all AS behaviors are horribly murky and
documentation worse, and achieving reliably predictable consistency a
frequent pipe dream. There's a reason I posted to the list first, you
know, because if I've made any mistakes in my analysis then they need
explicitly torn apart and fixed before I file a formal ticket.
Seriously Shane, platform security is a vastly greater and infinitely
more serious issue than all the personal loyalties/grudges/etc that you
or I might muster. It seriously impacts *millions* of people, geeks and
non-geeks alike, so if the most you can do is dismissively flip the
finger you're being no help to me, you, or anyone else (including your
mates at Apple) so best you save us the time and stay out of the
discussion altogether.
...
OK, so here's where I'm currently at in trying to get to the bottom of this:
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. It would be just as dangerously wrong if
it was Python/Objective-C/whatever doing it, BTW; if they did, I'd have
written exactly the same about them. (It's just that the chances of
Python/ObjC/etc ever being that stupid are vastly lower, and even if
they were they'd be instantly lynched by their immediate peers, long
before a slowpoke like me stumbles int them.)
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. For instance, if I add
'~/Documents/PyScripts' to PYTHONPATH in my ~/.bash_profile, Python
scripts I run in Terminal can now see libraries from within that folder;
however, a Python interpreter running within a process that doesn't read
~/.bash_profile (e.g. a GUI app) will not be affected by it, nor will
others users on the same system. (There's a *reason* Unix does
namespaces, you know.)
2. The ASLG also states that app-embedded 'Script Library' directories
(#3) appear on AS's library search paths *before* the standard 'Script
Libraries' paths (#4,#6,#8). So assuming the ASLG's description of how
library loading works is correct, then yes, the problem really is every
bit as bad as my post indicates. And if ASLG's description doesn't match
how the current implementation actually does it, then it's the current
implementation that's buggy (i.e. standard search paths must always come
*after* user-defined paths, allowing user-installed libraries to
intentionally mask standard libraries while ensuring that standard
libraries can never accidentally mask the user's).
At the same time, I have trouble getting a reliable step-by-step
reproduction worked out for the Apple Radar folks to follow. For
example, I've put a dummy 'Configuration Utility.scpt' in
'~/Library/Script Libraries' that currently seems to be getting loaded
ahead of the 'Configuration Utility.scpt' embedded in Apple
Configurator.app, contrary to what ASLG says and some of my testing
earlier today seemed to indicate. Take it out again, and the embedded
version gets loaded again.
Furthermore, there seems to be some degree of caching going on, possibly
in AS, possibly in SE, possibly in something else, because sometimes
when I move my dummy script in or out of the 'Script Libraries' folder
the test script still manifests the previous behavior the next time I
run it. Recompiling seems to make it catch up to the change, but that
itself is hardly a reassurance.
Oh, and just for the extra lulz, when I try running `osascript 'tell
script "Configuration Utility" to CNFGgetUtilityPath()'` in Terminal.app
(to see if the previous issue is due to SE), it doesn't seem to see the
app-embedded library at all and just reports "No such file or directory"
every time.
...
Without being able to examine the source code of whatever
searching/loading/caching mechanisms are being used by AS/SE/et al, I am
attempting to get all the way to the bottom of the whole mess out by
trying to black-box reverse-engineer it with only a Pooh stick to poke
it, and a Pooh brain to crunch the results. Expect updates and
corrections as new and better information arises. But even at the
*absolute bare-ass minimum*, and taking the most benevolent and
forgiving attitude possible, this is unpredictable, unreliable, unsafe,
and frankly incompetent software design, and does indeed represent a
security hole in OS X. (And I'm long since out of benevolence and
forgiveness - not to mention gum.) I expect this sort of thing from Ruby
cretins
<http://www.theregister.co.uk/2013/01/10/ruby_on_rails_security_vuln/>,
NOT Apple engineers.
So please, either *identify and correct* all of the errors you have
found in my initial analysis by providing a full and detailed
explanation of what *actually is going on*, along with evidence that
you've been over all the potential use cases, and the test code and
results for others to prove and reproduce it. (And by test code I don't
just mean the one cheerily trivial example of it working as intended,
but also all of the pathological corner cases that any competent
defensive coder, never mind professional pentester, knows to hunt for
and hammer on to see if they can break it.) Or sit quietly and let the
grown ups get on with grown-up stuff; it's all the same to me.
Regards,
has
p.s. And no, a whole fresh new ass-ripping sess is not the way I had
hoped to start 2016 either. But that's just one of life's many
disappointments we'll both have to live with.
_______________________________________________
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