Argentinian security company Core Labs (which is the core research group, if you will pardon the pun, of US-based Core Security Technologies) has just published a critique of Apple’s attitude to security.
In an article entitled A Tale of Two Advisories, the Core Labs researchers discuss vulnerabilities disclosed to Adobe and Apple, and the response of the two companies.
Adobe, apparently, reacted well. But Apple, says Core, was found wanting.
The claimed vulnerability is in Apple’s much-vaunted sandbox, a kernel-enforced system of application restrictions which software can use to harden itself against attackers.
For example, an application which doesn’t have any networking code can voluntarily subject itself to the no-network (or kSBXProfileNoNetwork) profile. This ought to allow the application to “promise” that, even in the presence of remote code execution bugs, it can’t be tricked by a hacker into providing network access.
According to Apple, anything sold or given away through the App Store “must implement sandboxing” by 2012-03-01.
I’d love to summarise what “must implement sandboxing” means, but the relevant App Sandbox page isn’t open to the public, or even to entry-level Apple Developers. Apple ought to rethink this restriction.
Since entry-level developers can download and use Apple’s development tools, it would be a good idea to have them thinking about sandboxing for OS X software of any sort. The publicly-available documentation seems to consist only of how to use the five predefined profiles shown above, which are listed when you run man sandbox_init.
The criticism from Core Labs is that, whilst sandbox restrictions apply recursively to processes directly spawned by a sandboxed application, they don’t apply to processes spawned indirectly.
So, for example, you can use Apple Script to tell OS X to start some other arbitrary program (or a second copy of your own) which won’t inherit your sandbox settings.
According to Core Labs, Apple’s response was problematic because the company merely offered to document more clearly that sandboxing restrictions can’t be assumed to apply to any process other than the sandboxed one.
Core Labs wants Apple to make its no-network sandbox profile mean exactly that, for any OS process initiated by a no-network program.
What happens next?
Will Apple harden up the sandbox as a result? Let’s hope so.
And let’s hope Apple will be much more open about its sandbox, and how get the best out of it.
Follow @duckblog
–
PS. Readers who are interested in the internals of Apple’s sandbox should read Dionysus Blazakis’s detailed analysis of it. Sandbox rules are written in a Lisp dialect (actually, TinyScheme 1.38), which is documented by Apple only as being an “Apple System Private Interface and subject to change at any time”.
Looking at some of the sample scripts in /usr/share/sandbox, and taking advice from Blazakis’s paper, a simple modification of the no-network policy gives a simple, if rather specific, workaround to the Core Labs “exploit.” Core Labs says to run its proof-of-concept like this:
$ sandbox-exec -n no-network python corelabsPoC.py 127.0.0.1
But a slightly stricter sandbox policy will prevent the existing PoC from doing its Apple Script trickery:
$ sandbox-exec -p '
>(version 1) (allow default) (deny network*)
>(deny process-exec (literal "/usr/bin/osascript"))
>' /usr/bin/python corelabsPoC.py 127.0.0.1
Once you’ve played with the sandbox a little, you’re sure to want to know more. C’mon, Apple! The Bad Guys will find the holes even if you keep the secrecy up. Let the Good Guys play in the sandbox, too!
Leave a reply
