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: Shane Stanley <email@hidden>
- Date: Wed, 06 Jan 2016 16:51:12 +1100
On 6 Jan 2016, at 12:31 PM, has <email@hidden> wrote:
>
> 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
Then how about we stick to the issue, rather than treating it as another excuse to trot out your personal grudges (yet again). The style might entertain some, but the content is a rather sad reflection, not to mention more than a bit repetitive.
>
> 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.
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.
> 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.
>
> 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.
I think it's wrong, as I posted elsewhere. But part of your point still holds, in terms of /Library, not ~/Library.
> 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.
The latter matches what I see here. (Actually, I built a new app with an embedded library and tested that, just to make sure.) ~/Library loads before /Applications, but /Applications loads before /Library. FWIW, if you're arguing that /Applications should be lower down the order, or last, I'd agree. (And honestly, if it disappeared, I can't see that it would be any great loss. But maybe I'm missing something.) I wonder if your earlier testing was thrown out by lib caching.
>
> 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.
Compiling is creating a new AS component instance. I suspect that once a lib named X is cached in a component, its source is irrelevant; that's X for that component. But if the lib has an .sdef, the changed mod date for the bundle might might trigger some kind of .sdef-related flushing. Just speculating.
>
> 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.
AppleScript is a security hole. The rest is a matter of degrees, and making pragmatic judgments.
> (And I'm long since out of benevolence and forgiveness - not to mention gum.)
Let's hope the vitriole starts running low soon, too.
>
> 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.)
You mean like you did?
> Or sit quietly and let the grown ups get on with grown-up stuff; it's all the same to me.
If all the name-calling is grown-up behavior, I'm glad I dodged it.
FWIW, if anyone's really concerned, putting libs in ~/Library rather than /Library seems to short-circuit things. And if you're really serious about security, that probably goes for most things that can be put in either -- don't give anything more access than it needs.
So far we have exactly one known case of a lib in an app, and exactly zero cases of standardLib, so the chances of anything happening are pretty slim. I'd expect the App Store to vet any apps, but then that's a whole other story. And I'd expect most malcontents to aim for a slightly wider audience than everyone who might be using a particular script library.
That said, I'm not sure I see a lot of value in apps loading libs -- it looks to me like it's something that might have been added to get scripting where it wasn't otherwise going to be, but I'm yet to be convinced of any general value. And the definition of "installed applications" might well be a bit broad (applets?). I can't see that removing it, even if only for the warm feeling, is going to leave the scripting world a particularly poorer place. And if it stays, I think it should definitely be lower down the search order.
I'd also like to see the option to address libs by bundle ID, and optionally specify full paths. I filed a radar on the former ages ago, but feel free to pile on the votes.
--
Shane Stanley <email@hidden>
<www.macosxautomation.com/applescript/apps/>
_______________________________________________
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