Mac OS X Sandbox Security Hole Uncovered

Researchers at Core Security Technologies have uncovered a security hole that could allow someone to circumvent the application sandbox restrictions of Mac OS X.

Apple sandboxResearchers at Core Security Technologies have uncovered a security hole that could allow someone to circumvent the application sandbox restrictions of Mac OS X.

The report of the vulnerability, which affects Mac OS X 10.7x, 10.6x and 10.5x, follows Apple’s announcement earlier this month that all applications submitted to the Mac App store must implement sandboxing as of March 1, 2012. Sandboxing, Apple has argued, limits the resources applications can access and makes it more difficult for malware to compromise systems.  

Researchers at Core however revealed Nov. 10 that they had warned Apple in September about a vulnerability in their sandboxing approach. According to Core’s advisory, several of the default predefined sandbox profiles fail to “properly limit all the available mechanisms.” As a result, the sandboxing restrictions can be circumvented through the use of Apple events.

In Core’s proof-of-concept, researchers used “osascript” to send the required Apple events to “launchd” in order to execute the new process. Since the new process is not a child of the sandboxed process, it is created without the sandbox restrictions, Core explained in its advisory. The end result was that the researchers were able to get around the prohibition on sockets-based networking that is part of the no-network profile.

“Let’s say that there is an address book application you do not trust and run within the no-network profile,” Ariel Waissbein, director of CoreLabs, Core Security Technologies’ research arm, told Threat Post. “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. This is clearly a violation of the expected behavior.”

“The users and developers have a false sense of security,” he continued. “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 did not respond to a request for comment about the matter from Threat Post. 

“What makes this more interesting is the vulnerability found by CoreLabs within the Apple OX Sandbox is very similar to the issues (security researcher) Charlie Miller found and reported in 2008 at Black Hat Japan,” blogged Alex Horan, senior product manager with Core Security. “At that time Apple modified the profile to prevent the vulnerability reported from being triggered, so the question remains why has Apple chosen not to do that in this instance?”

According to the firm, Apple responded Oct. 18 by stating it is considering changing the language in the documentation to make it clear that the restrictions these particular sandbox profiles provide are limited to the process in which the sandbox is applied.

The disclosure capped a week of security news for Apple that saw the company generate mixed reaction for ejecting Miller from its developer program after he placed a proof-of-concept application in the Apple App Store to demonstrate a vulnerability in iOS. The vulnerability was patched in an iOS update released Nov. 10.

Suggested articles


  • drstrangep0rk on

    Old but interesting new. You may want to check /usr/share/sandbox and look at all the example profiles, good idea to write your own. The examples in that directory are documented. The problem is actually as stated on their site the following.

    "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. Namely, sending Apple events is possible within the no-network sandbox (kSBXProfileNoNetwork)"

    A custom sand-box with the following may help.

    (deny network-outbound)

    (allow network-outbound (to unix-socket)) (deny network*)

    I think this again was a Charlie Miller production, Core just picked up and epanded as they stated.


    May be a good time to read the man page since I think there are only five and the documentation may be more specific about the aviable profiles. (Could be a good time to read about them, try it out. ) Is there a conjuction that will make it far more difficult for an attacker. Good time to check the man pages. 

    Man Page

     SANDBOX_INIT(3) BSD Library Functions Manual SANDBOX_INIT(3) NAME sandbox_init, sandbox_free_error -- set process sandbox SYNOPSIS #include <sandbox.h> int sandbox_init(const char *profile, uint64_t flags, char **errorbuf); void sandbox_free_error(char *errorbuf); DESCRIPTION sandbox_init() places the current process into a sandbox(7). The NUL-terminated string profile speci- fies the profile to be used to configure the sandbox. The flags specified are formed by or'ing the following values: SANDBOX_NAMED The profile argument specifies a sandbox profile named by one of the constants given in the AVAILABLE PROFILES section below. The out parameter *errorbuf will be set according to the error status. RETURN VALUES Upon successful completion of sandbox_init(), a value of 0 is returned and *errorbuf is set to NULL. In the event of an error, a value of -1 is returned and *errorbuf is set to a pointer to a NUL-termi- nated string describing the error. This string may contain embedded newlines. This error information is suitable for developers and is not intended for end users. This pointer should be passed to sandbox_free_error(3) to release the allocated storage when it is no longer needed. AVAILABLE PROFILES The following are brief descriptions of each available profile. Keep in mind that sandbox(7) restric- tions are typically enforced at resource acquisition time. kSBXProfileNoInternet TCP/IP networking is prohibited. kSBXProfileNoNetwork All sockets-based networking is prohibited. kSBXProfileNoWrite File system writes are prohibited. kSBXProfileNoWriteExceptTemporary File system writes are restricted to the temporary folder /var/tmp and the folder specified by the confstr(3) configuration variable _CS_DARWIN_USER_TEMP_DIR. kSBXProfilePureComputation All operating system services are prohibited. SEE ALSO

    Specific from CORE SECURITY.

    8. Technical Description / Proof of Concept Code

    The use of Apple events is possible within the several default profiles as no-network, no-internet (kSBXProfileNoNetwork, kSBXProfileNoInternet) and others. 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.


    Thanks for the reporting on this. 

  • ylliqzkpgb on

    long year acer trends show only 001 more acelenolysunci topics now pr61 in 2012
  • tsngjkloig on

    long year acer trends show only 001 more acelenolysunci topics now pr60 in 2012
  • inyvndqcer on

    long year acer trends show only 001 more acelenolysunci topics now pr57 in 2012

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.