Apple OS X sandbox hole allows bypassing of restrictions

Following Apple’s announcement that all applications submitted for inclusion in the App Store will have to have sandboxing implemented starting from March 1, 2012, researchers from Core Labs, the research arm of Core Security Technologies, have decided to analyze whether this requirement and the sandboxing practice offer the protection that app developers and Apple believe it does.

Unfortunately (or fortunately – depends on how you look at it), they discovered a security flaw that allows malicious individuals to “escape” the sandbox.

“Several of the default pre-defined sandbox profiles don’t properly limit all the available mechanisms and therefore allow exercising part of the restricted functionality,” explain the researchers in an advisory. “Namely, sending Apple events is possible within the no-network sandbox (kSBXProfileNoNetwork). A compromised application hypothetically restricted by the use of the no-network profile may have access to network resources through the use of Apple events to invoke the execution of other applications not directly restricted by the sandbox.”

Apple has been notified of the issue back in September. At first it replied to the researchers that it does not see any actual security implications, as the kSBXProfileNoNetwork sandbox profile does not promise that Apple Events will be blocked in the documentation.

The researchers replied by sending their proof-of-concept code and pointed out that Apple should modify its documentation to explicitly say that the restrictions that these particular sandbox profiles provide are limited to the process in which the sandbox is applied, to which Apple responded that it’s currently thinking about doing it.

“Let’s say that there is an address book application you do not trust and run within the no-network profile. Assume that an attacker provides you with a file containing his contact information and that a vulnerability in the address book allows the malicious user to take control of the application. While the malicious user should be only allowed to tamper with the application (and for example) delete its contents, he may also send the contents back to himself,” CoreLabs’s director Ariel Waissbein, commented for Threat Post. “This is clearly a violation of the expected behavior. The users and developers have a false sense of security. While they expect that applications run in these restricted sandbox profiles have one behavior, they may behave in a different way – and in particular, allow for resources that they thought were restricted.”

Apple has still not offered an official statement on the matter. The question is: will it simply modify the documentation or will it harden its sandbox in order to prevent the starting of possibly malicious processes that have been created indirectly by a sandboxed app? Security-minded individuals will obviously be rooting for the latter option.