Apple OS X Sandbox Predefined Profiles Bypass
Today I wanna mention a little bug we found together with Matias Eissler. It’s not the big thing, that’s clear. But it’s potentially dangerous and it shows the complexity of a sandbox implementation.
This is the story: After a few hours fooling around with the sandbox, we found this method that allowed us to bypass the network access restriction. The funny thing here is that we did a quick search on google about the topic to see if some of this was reported before and guess what? Charlie Miller publicly disclosed the same thing (that apple events were allowed in a sandbox profile) in the quicklookd profile like 3 years ago.
So, when we checked the current version of the profile and saw that it was modified to also restrict apple events we though: “Ok, if Apple modified the profile after Charlie’s talk, they recognize the issue as a vulnerability, or at least as a problem”.
Well, they actually recognized the issue, and they are considering to ‘modify the documentation’ to explicily point this out. Better than nothing, but that means that by the time, the no-network sandbox profile doesn’t actually restrict network access. Funny huh?
Some articles mentioning the issue:
Some words about the comments I’ve seen regarding the issue: It doesn’t affect the applications sandboxed directly from the source code. This issue only exist (as Apple suggests) when a user runs a -maybe untrusted- binary application in a sandboxed environment through the sandbox-exec command. Althought that is a problem itself, because the user would get a false sense of security, I think the main problem is that those profiles are provided as some sort of example. If a developer, for instance, defines a sandbox environment for a critical application based on that rules, the new application will be as insecure as the default profiles.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Core Security - Corelabs Advisory http://corelabs.coresecurity.com/ Apple OS X Sandbox Predefined Profiles Bypass 1. *Advisory Information* Title: Apple OS X Sandbox Predefined Profiles Bypass Advisory ID: CORE-2011-0919 Advisory URL: http://www.coresecurity.com/content/apple-osx-sandbox-bypass Date published: 2011-11-10 Date of last update: 2011-11-10 Vendors contacted: Apple Release mode: User release 2. *Vulnerability Information* Class: Access control failure [CWE-264] Impact: Code execution Remotely Exploitable: Yes Locally Exploitable: No CVE Name: CVE-2011-1516 3. *Vulnerability Description* 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 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. It is worth mentioning that a similar issue was reported by Charlie Miller in his talk at Black Hat Japan 2008 . He mentioned a few processes sandboxed by default as well as a method to circumvent the protection. Sometime after the talk, Apple modified the mentioned profiles by restricting the use of Apple events but did not modify the generic profiles. 4. *Vulnerable packages* . Apple Mac OS X 10.7.x . Apple Mac OS X 10.6.x . Apple Mac OS X 10.5.x 5. *Non-vulnerable packages* . Apple Mac OS X 10.4 6. *Vendor Information, Solutions and Workarounds* Contact the vendor for more information. 7. *Credits* This vulnerability was discovered and researched by Anibal Sacco and Matias Eissler from Core Security Technologies. The publication of this advisory was coordinated by Carlos Sarraute. 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. As Apple's "App Sandbox Design Guide" document points out, applications that require sending Apple events to other arbitrary applications are not suitable for sandboxing, because some developer tools restrict Apple events by default while defining the sandbox. The reason for this is that, as we show here, by dispatching Apple events a process can escape the sandbox . The method used by Charlie Miller involves dropping a script to the disk and getting it executed by launchd via launchctl. Our approach is technically the same without the need to drop a file. In our PoC we used "osascript" to send the required Apple events to launchd in order to execute the new process. As the new process is not a 'child' of the sandboxed process, it is created without the sandbox restrictions. An additional risk with these profiles is that they are supposed to provide an example of how a process should be restricted in different scenarios. If the no-network profile allows Apple-script events, this may result in new applications using the same restriction rules, therefore offering a false sense of security. The following PoC illustrates this vulnerability: /----- import os import sys import socket if len(sys.argv) != 2: print "[-] Usage: sandbox-exec -n no-network python %s hostname" % sys.argv try: targetIP = sys.argv s = socket.socket() s.connect((targetIP, 80)) s.send('GET /\r\n\r\n') print(s.recv(1024)) print "\n\n\n[+] Sandbox escaped" except Exception, e: if "Operation not permitted" in str(e): #print repr(e) print "[-] Blocked by seatbelt" print "[ ] Escaping..." os.system("""/usr/bin/osascript -e 'tell application "Terminal" to do script "python %s %s"'""" % (sys.argv, targetIP)) - -----/ 9. *Report Timeline* . 2011-09-20: Core Security Technologies notifies Apple Product Security of the vulnerability, including technical details. Preliminary publication date is set to November 7, 2011. . 2010-09-20: Vendor acknowledges the receipt of the information. . 2010-10-05: Vendor informs that it does not see any actual security implications. The kSBXProfileNoNetwork sandbox profile does not promise that Apple Events will be blocked in the documentation. (Specifically, all it guarantees is "all sockets-based networking is prohibited".) . 2011-10-13: Core responds that the kSBXProfileNoNetwork sandbox profile should guarantee that "all sockets-based networking is prohibited". The PoC sent to Apple shows that through the use of Apple events (osascript is used in the PoC just to keep it simple) an attacker could circumvent the restriction. So, at the end, sockets-based networking is used. . 2010-10-18: Vendor responds that it is currently considering modifying its documentation to explicitly point out what Core described; namely, that the restrictions that these particular sandbox profiles provide are limited to the process in which the sandbox is applied. . 2011-11-10: The advisory CORE-2011-0919 is published as user release. 10. *References*  App Sandbox Design Guide -- Designing for App Sandbox http://developer.apple.com/library/mac/#documentation/Security/Conceptual/AppSandboxDesignGuide/DesigningYourSandbox/DesigningYourSandbox.html  Charlie Miller, "Hacking OS X", Black Hat Japan 2008 https://www.blackhat.com/presentations/bh-jp-08/bh-jp-08-Miller/BlackHat-Japan-08-Miller-Hacking-OSX.pdf 11. *About CoreLabs* CoreLabs, the research center of Core Security Technologies, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: http://corelabs.coresecurity.com. 12. *About Core Security Technologies* Core Security Technologies enables organizations to get ahead of threats with security test and measurement solutions that continuously identify and demonstrate real-world exposures to their most critical assets. Our customers can gain real visibility into their security standing, real validation of their security controls, and real metrics to more effectively secure their organizations. Core Security's software solutions build on over a decade of trusted research and leading-edge threat expertise from the company's Security Consulting Services, CoreLabs and Engineering groups. Core Security Technologies can be reached at +1 (617) 399-6980 or on the Web at: http://www.coresecurity.com. 13. *Disclaimer* The contents of this advisory are copyright (c) 2011 Core Security Technologies and (c) 2011 CoreLabs, and are licensed under a Creative Commons Attribution Non-Commercial Share-Alike 3.0 (United States) License: http://creativecommons.org/licenses/by-nc-sa/3.0/us/ 14. *PGP/GPG Keys* This advisory has been signed with the GPG key of Core Security Technologies advisories team, which is available for download at http://www.coresecurity.com/files/attachments/core_security_advisories.asc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) iEYEARECAAYFAk68OxMACgkQyNibggitWa0YWgCfYbGm9R0+YJw6CxP6TNwdhEWr 9ZMAn16nqBqNbO582D5QpejeuTEV5RAj =HruN -----END PGP SIGNATURE-----