SandScout: Automatic Detection of Flaws in iOS Sandbox Profiles Luke Deshotels Razvan˘ Deaconescu Mihai Chiroiu North Carolina State University POLITEHNICA of University POLITEHNICA of University Bucharest Bucharest [email protected] razvan.deaconescu@ mihai.chiroiu@ cs.pub.ro cs.pub.ro Lucas Davi William Enck Ahmad-Reza Sadeghi Technische Universität North Carolina State Technische Universität Darmstadt, Germany University Darmstadt, Germany [email protected] [email protected] [email protected] ABSTRACT application code to provide additional security. All of these Recent literature on iOS security has focused on the ma- works rely on interacting with the code of third-party iOS licious potential of third-party applications, demonstrating applications. how developers can bypass application vetting and code- We investigate something different: iOS sandbox profiles. level protections. In addition to these protections, iOS uses These sandbox profiles define access control policies for sys- a generic sandbox profile called \container" to confine ma- tem calls made by processes. There are 117 sandbox profiles licious or exploited third-party applications. In this paper, in the iOS 9.0.2 kernel, and many system daemons and ap- we present the first systematic analysis of the iOS container plications have dedicated profiles. However, all third-party sandbox profile. We propose the SandScout framework to applications, and some system applications, are confined us- extract, decompile, formally model, and analyze iOS sand- ing the shared \container" sandbox profile. The container box profiles as logic-based programs. We use our Prolog- sandbox profile is large and complex, leading to the research based queries to evaluate file-based security properties of the question: what flaws in the container sandbox profile can container sandbox profile for iOS 9.0.2 and discover seven third-party iOS applications exploit? classes of exploitable vulnerabilities. These attacks affect Goals and Contributions: In this paper, we present non-jailbroken devices running later versions of iOS. We are the SandScout framework to answer this research question. working with Apple to resolve these attacks, and we expect First, we create a tool, SandBlaster, which automatically that SandScout will play a significant role in the develop- extracts compiled profiles from a firmware image and de- ment of sandbox profiles for future versions of iOS. compiles them into their original SandBox Profile Language (SBPL). Second, we formally model sandbox profiles using Prolog by creating a compiler that automatically translates 1. INTRODUCTION SBPL policies into Prolog facts. Third, we develop Prolog The sale of smartphones has out-paced the sale of queries that test critical security properties of the container PCs [15]. The two dominant platforms for these smart sandbox policy. The queries identify potential security vul- phones are Android and iOS [16]. There has been a sig- nerabilities in the policy. Finally, we create an iOS applica- nificant amount of academic research on Android, in part, tion that provides assisted verification of potential vulnera- because of its open-source nature. In contrast, iOS is not bilities on iOS devices. open-source, and studies of iOS may require significant re- We use SandScout to evaluate the container sandbox pro- verse engineering effort. file for iOS 9.0.2. Sandbox profiles mediate all system calls Prior research on iOS security has focused on the follow- including file access and inter-process communication (IPC). ing three areas. First, works have demonstrated methods For this evaluation, we limit our security queries to file-based for creating iOS malware [48, 22, 33, 52, 40, 47]. Second, sandbox policy rules for two reasons. First, non-file-based others emphasize methods to detect malicious behavior ei- sandbox policy rules require additional semantics that are ther statically [29] or dynamically [28]. Third, new security not available in the policy. Second, we find significant se- mechanisms [22, 26, 50] have been proposed that hook into curity vulnerabilities within the file-based sandbox policy rules. We plan to expand our analysis to non-file-based pol- icy rules in future work. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed Our analysis of the file-based policy rules in the iOS for profit or commercial advantage and that copies bear this notice and the full cita- 9.0.2 container sandbox profile identified seven broad vul- tion on the first page. Copyrights for components of this work owned by others than nerabilities that are exploitable by third-party applications: ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re- publish, to post on servers or to redistribute to lists, requires prior specific permission (1) methods of bypassing iOS's privacy settings for Con- and/or a fee. Request permissions from [email protected]. tacts; (2) methods of learning a user's location search his- CCS’16, October 24-28, 2016, Vienna, Austria tory; (3) methods of inferring sensitive information by ac- c 2016 ACM. ISBN 978-1-4503-4139-4/16/10. $15.00 cessing metadata of system files; (4) methods of obtaining DOI: http://dx.doi.org/10.1145/2976749.2978336 the user's name and media library; (5) methods of consum- and executable at the same time. ASLR mitigates code- ing disk storage space that cannot be recovered by unin- reuse attacks by randomizing code and data segments in stalling the malicious app; (6) methods of preventing access memory. Interestingly, code signing complicates the ASLR to system resources such as the AddressBook; (7) methods design and limits its protection, because shuffling code re- for colluding applications to communicate without using iOS gions may invalidate signatures [2]. Prior work [48, 22, 42, sanctioned IPC. We have reported all of these vulnerabili- 34] has demonstrated several techniques for bypassing ap- ties to Apple and are working with them to ensure they are plication vetting and memory protections. fixed in future versions of iOS. iOS sandboxes all applications using a mandatory access This paper makes the following contributions: control policy to limit the abilities of exploited or malicious code. Sandbox policies are enforced by the Trusted BSD • We develop the first methods to automatically produce mandatory access control framework [18] using a kernel ex- human readable SBPL policies. Prior work was unable tension called Sandbox.kext. iOS uses different sandbox poli- to produce SBPL policies for human review or auto- cies (called profiles) for different applications. Many system mated analysis. Our tool extracts and decompiles all applications and daemons have their own profile. However, sandbox profiles in firmwares for iOS 7, 8, and 9. all third-party applications are controlled by a generic sand- box profile called container. The container sandbox profile • We formally model SBPL policies using Prolog. We is also used by several system applications. In order to sup- create an SBPL to Prolog compiler based on a context port the functionality of many different applications, it is free grammar we have defined for SBPL. the largest and most complex sandbox profile. • We perform the first systematic evaluation of the con- Sandbox profile rules define access to system calls (e.g., tainer sandbox profile for recent versions of iOS and file read and write). To be generic, the container sandbox discover vulnerabilities. We develop Prolog queries profile uses conditional rules that may require capabilities. representing security requirements. When applied to There are two primary types of capability considered by the the iOS 9.0.2 container sandbox profile, we discover sandbox: entitlements and sandbox extensions. Mentioned seven classes of security vulnerabilities. above, entitlements are static capabilities assigned by ap- plication's developer during development. Entitlements are The remainder of the paper proceeds as follows. Section 2 key-value pairs, which are stored in a dictionary structure provides background information. Section 3 provides an embedded in an application's code signature. Note that en- overview of SandScout. Section 4 discusses our design. Sec- titlement keys are not cryptographic keys, and they simply tion 5 presents our results. Section 6 provides discussion of map to values in the entitlement dictionary. Once the ap- our limitations. Section 7 presents related work. Section 8 plication has been signed, its entitlements cannot be mod- concludes. ified without invalidating the signature. In contrast, sand- box extensions are dynamic capabilities that can be granted 2. BACKGROUND or revoked at run time. System daemons such as the tccd daemon, which helps enforce iOS's user specified Privacy iOS is the operating system of the iPhone, iPod, iPad, Settings, can grant sandbox extensions. and older versions of AppleTV (newer AppleTV devices run Finally, while the vast majority of iOS's access control TVOS). iOS is based largely on Apple's desktop operating policy is enforced in using sandbox profiles, system, OS X, and the two share many internal similarities. Sandbox.kext there are various access control checks within system dae- 2.1 iOS Security Mechanisms mons. These system daemons maintain their own policies based on user preferences (e.g., for Privacy Settings) and iOS relies on four broad types of security mechanisms: ap- entitlements. In this paper, we limit our investigation to plication vetting, code signing, memory protection, and sand- the sandbox profiles and leave these other daemon specific boxing. When developers submit an application to the App access control policies to future work. Store [7] for vetting, they sign the application using their de- veloper key. While the specific details of the vetting process are only known to Apple, it is assumed that they use a com- 2.2 Sandbox Profile Language (SBPL) bination of static and dynamic analysis to detect malicious Sandbox profiles are written in the SandBox Profile Lan- behavior.