Researchers 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.
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
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.
long year acer trends show only 001 more acelenolysunci topics now pr61 in 2012
long year acer trends show only 001 more acelenolysunci topics now pr60 in 2012
long year acer trends show only 001 more acelenolysunci topics now pr57 in 2012