ASM: a Programmable Interface for Extending Android Security
Total Page:16
File Type:pdf, Size:1020Kb
ASM: A Programmable Interface for Extending Android Security Stephan Heuser, Intel CRI-SC at Technische Universität Darmstadt; Adwait Nadkarni and William Enck, North Carolina State University; Ahmad-Reza Sadeghi, Technische Universität Darmstadt and Center for Advanced Security Research Darmstadt (CASED) https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/heuser This paper is included in the Proceedings of the 23rd USENIX Security Symposium. August 20–22, 2014 • San Diego, CA ISBN 978-1-931971-15-7 Open access to the Proceedings of the 23rd USENIX Security Symposium is sponsored by USENIX ASM: A Programmable Interface for Extending Android Security * Stephan Heuser∗ Adwait Nadkarni [email protected] [email protected] Intel CRI-SC at TU Darmstadt North Carolina State University William Enck Ahmad-Reza Sadeghi [email protected] [email protected] North Carolina State University TU Darmstadt / CASED Abstract such as “get location,” “take picture,” and “search ad- dress book.” The availability of these semantically rich Android, iOS, and Windows 8 are changing the applica- OS APIs vastly simplifies application development, and tion architecture of consumer operating systems. These has led to an explosive growth in the number and diver- new architectures required OS designers to rethink secu- sity of available applications. rity and access control. While the new security archi- These functional changes caused OS designers to re- tectures improve on traditional desktop and server OS think security. The new application abstractions both en- designs, they lack sufficient protection semantics for dif- able and necessitate assigning each user application to a ferent classes of OS customers (e.g., consumer, enter- unique protection domain, rather than executing all user prise, and government). The Android OS in particular applications with the user’s ambient authority (the norm has seen over a dozen research proposals for security in traditional OSes such as Windows and UNIX). By de- enhancements. This paper seeks to promote OS secu- fault, each application’s protection domain is small, often rity extensibility in the Android OS. We propose the An- containing only the OS APIs deemed not to be security droid Security Modules (ASM) framework, which pro- sensitive and the files it creates. The application must be vides a programmable interface for defining new refer- granted capabilities to access the full set of semantically ence monitors for Android. We drive the ASM design by rich OS APIs. This security model provides a better ap- studying the authorization hook requirements of recent proximation of least privilege, which limits both the im- security enhancement proposals and identify that new pact of an exploited application, as well as the authority OSes such as Android require new types of authorization granted to a Trojan. However, how and when to grant hooks (e.g., replacing data). We describe the design and these privileges has been the topic of much debate [16]. implementation of ASM and demonstrate its utility by For the last several years, the security research com- developing reference monitors called ASM apps. Finally, munity has contributed significant discourse on the right ASM is not only beneficial for security researchers. If security architecture for these new operating systems. adopted by Google, we envision ASM enabling in-the- Android has been the focus of this discourse, mostly due field security enhancement of Android devices without to its open source foundation, widespread popularity for requiring root access, a significant limitation of existing mobile devices, and the emergence of malware targeting bring-your-own-device solutions. it. In the relatively short period of time since the An- droid platform’s initial release in 2008, there have been 1 Introduction more than a dozen proposals for new Android security architectures [15, 24, 14, 23, 10, 7, 8, 37, 6, 19, 18, 12, Consumer operating systems are changing. Android, 9, 22, 29]. As we discuss in this paper, while these secu- iOS, and Windows 8 place a high priority on the user- rity architecture proposals have very diverse motivations, application experience. They provide new abstractions their implementations often share hook placements and for developing user-applications: applications fill the enforcement mechanisms. screen; they have complex lifecycles that respond to The primary goal of this paper is to promote OS secu- user and system events; and they use semantically rich rity extensibility [33] in the Android platform. History OS provided application programming interfaces (APIs) has shown that simply providing type enforcement, in- formation flow control, or capabilities does not meet the ∗These authors contributed equally to this work. demands of all potential OS customers (e.g., consumers, USENIX Association 23rd USENIX Security Symposium 1005 enterprise, government). Therefore, an extensible OS se- need to change, eliminating the need to port each re- curity interface must be programmable [33]. In short, we search project to new versions. ASM can provide even seek to accomplish for Android what the LSM [34] and greater benefit if it is adopted into the Android Open TrustedBSD [32] frameworks have provided for Linux Source Project (AOSP): ASM apps can be added without and BSD, respectively. What makes this task interesting source code modification. Ultimately, we envision an in- and meaningful to the research community is the pro- terface that allows enterprise IT and researchers to load cess of determining the correct semantics of authoriza- ASM apps on production phones without root access. tion hooks for this new OS architecture. The remainder of this paper proceeds as follows. Sec- In this paper, we propose the Android Security Mod- tion 2 provides a short background on Android. Section 3 ules (ASM) framework, which provides a set of autho- defines high level goals that underlie the ASM design. rization hooks to build reference monitors for Android Section 4 surveys recent work enhancing Android secu- security. We survey over a dozen recent Android secu- rity and identifies a common set of authorization hook se- rity architecture proposals to identify the hook seman- mantics. Section 5 describes the ASM design. Section 6 tics required of ASM. Of particular note, we identify the evaluates the utility and performance of ASM. Section 7 need to (1) replace data values in OS APIs, and (2) allow highlights related work on OS security extensibility. Sec- third-party applications to define new ASM hooks. We tion 8 concludes. design and implement an open source version of ASM within Android version 4.4 and empirically demonstrate negligible overhead when no security module is loaded. 2 Background ASM fulfills a strong need in the research community. It The Android OS is based on a Linux kernel, but pro- provides researchers a standardized interface for security vides a substantially different application abstraction architectures and will potentially lead to field enhance- than found in traditional Linux desktop and server dis- ment of devices without modifying the system firmware tributions. Android applications are written in Java and (e.g., BYOD), if adopted by Google. compiled into a special DEX bytecode that executes in This paper makes the following contributions: Android’s Dalvik virtual machine. Applications may op- We identify the authorization hook semantics re- tionally contain native code components. Application • quired for new operating systems such as Android. functionality is divided into components. Android de- The Android OS is responsible for enforcing more fines four types of components: activity, service, broad- than just UNIX system calls. Android includes se- cast receiver, and content provider. The application’s mantically rich OS APIs and new application lifecy- user interface is composed of a set of activity compo- cle abstractions that must be included in OS access nents. Service components act as daemons, providing control. We also identify the need for authorization background processing. Broadcast receiver components hooks to replace data values and for third-party ap- handle asynchronous messages. Content provider com- plications to introduce new authorization hooks. ponents are per-application data servers that are queried by other applications. We design and implement the extensible Android Se- • Application components communicate with one an- curity Modules (ASM) framework. ASM brings OS other using Binder interprocess communication (IPC). security extensibility to Android. It allows mul- Binder provides message passing (called parcels) and tiple simultaneous ASM apps to enforce security thread management. In addition to data values, parcels requirements while minimizing performance over- can pass references to other binder objects as well as file head based on the required authorization hooks. descriptors. When an application holds a reference to a service component binder object, it can execute remote We implement two example ASM apps to demon- • procedure calls (RPCs) for any methods defined by that strate the utility of the ASM framework. ASM al- service. Most of Android’s semantically rich OS APIs lowed the fast development of useful example ASM are implemented as RPCs to OS defined service com- apps with functionalities similar to MockDroid [6] ponents. The OS also defines several content provider and password protected apps. components (e.g., address book) that are queried using