-----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 [2]. 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 [1].
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[0]
try:
targetIP = sys.argv[1]
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[0], 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*
[1] App Sandbox Design Guide -- Designing for App Sandbox
http://developer.apple.com/library/mac/#documentation/Security/Conceptual/AppSandboxDesignGuide/DesigningYourSandbox/DesigningYourSandbox.html
[2] 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-----
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
