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