Privilege Escalation Attacks on Android Lucas Davi, Alexandra Dmitrienko?, Ahmad-Reza Sadeghi, Marcel Winandy System Security Lab Ruhr-University Bochum, Germany {lucas.davi, alexandra.dmitrienko, ahmad.sadeghi, marcel.winandy}@trust.rub.de Abstract. Android is a modern and popular software platform for smart- phones. Among its predominant features is an advanced security model which is based on application-oriented mandatory access control and sandboxing. This allows developers and users to restrict the execution of an application to the privileges it has (mandatorily) assigned at instal- lation time. The exploitation of vulnerabilities in program code is hence believed to be confined within the privilege boundaries of an application���s sandbox. However, in this paper we show that a privilege escalation at- tack is possible. We show that a genuine application exploited at runtime or a malicious application can escalate granted permissions. Our results immediately imply that Android���s security model cannot deal with a transitive permission usage attack and Android���s sandbox model fails as a last resort against malware and sophisticated runtime attacks. 1 Introduction Mobile phones play an important role in today���s world and have become an integral part of our daily life as one of the predominant means of communica- tion. Smartphones are increasingly prevalent and adept at handling more tasks from web-browsing and emailing, to multimedia and entertainment applications (games, videos, audios), navigation, trading stocks, and electronic purchase. However, the popularity of smartphones and the vast number of the correspond- ing applications makes these platforms also more attractive targets to attackers. Currently, various forms of malware exist for smartphone platforms, also for An- droid [33, 8]. Moreover, advanced attack techniques, such as code injection [17], return-oriented programming (ROP) [29] and ROP without returns [6] affect ap- plications and system components at runtime. As a last resort against malware and runtime attacks, well-established security features of today���s smartphones are application sandboxing and privileged access to advanced functionality. Re- sources of sandboxed applications are isolated from each other, additionally, each application can be assigned a bounded set of privileges allowing an application to use protected functionality. Hence, if an application is malicious or becomes compromised, it is only able to perform actions which are explicitly allowed ? Supported by the Erasmus Mundus External Co-operation Window Programme of the European Union

in the application���s sandbox. For instance, a malicious or compromised email client may access the email database as it has associated privileges, but it is not permitted to access the SMS database. Android implements application sandboxing based on an application-oriented mandatory access control. Technically, this is realized by assigning each appli- cation its own UserID and a set of permissions, which are fixed at installation time and cannot be changed afterwards. Permissions are needed to access system resources or to communicate with other applications. Android checks correspond- ing permission assignments at runtime. Hence, an application is not allowed to access privileged resources without having the right permissions. However, in this paper we show that Android���s sandbox model is concep- tually flawed and actually allows privilege escalation attacks. While Android provides a well-structured permission system, it does not protect against a tran- sitive permission usage, which ultimately results in allowing an adversary to perform actions the application���s sandbox is not authorized to do. Note that this is not an implementation bug, but rather a fundamental flaw. In particular, our contributions are as follows: ��� Privilege escalation attacks: We describe the conceptual weakness of An- droid���s permission mechanism that may lead to privilege escalation attacks (Section 3). Basically, Android does not deal with transitive privilege usage, which allows applications to bypass restrictions imposed by their sandboxes. ��� Concrete attack scenario: We instantiate the permission escalation at- tack and present the details of our implementation (Section 4). In particular, in our attack a non-privileged and runtime-compromised application is able to bypass restrictions of its sandbox and to send multiple text messages to a phone number chosen by the adversary. Technically, for runtime compromise we use a recent memory exploitation technique, return-oriented program- ming without returns [9, 6], which bypasses memory-protection mechanisms and return-address checkers and hence assumes a strong adversary model. As a major result, our findings imply that Android���s sandbox model practi- cally fails in providing confinement boundaries against runtime attacks. Because the permission system does not include checks for transitive privilege usage, attackers are able to escape out of Android���s sandbox. 2 Android Before we elaborate on our attack, we briefly describe the architecture of Android and its security mechanisms. 2.1 Android Architecture Android is an open source software platform for mobile devices. It includes a Linux kernel, middleware framework, and core applications. The Linux kernel provides low-level services to the rest of the system, such as networking, storage,

memory, and processing. A middleware layer consists of native Android libraries (written in C/C++), an optimized version of a Java Virtual Machine called Dalvik Virtual Machine (DVM), and core libraries written in Java. The DVM executes binaries of applications residing in higher layers. Android applications are written in Java and consist of separated modules, so-called components. Components can communicate to each other and to components of other appli- cations through an inter component communication (ICC) mechanism provided by the Android middleware called Binder1. As Android applications are written in Java, they are basically protected against standard buffer overflow attacks [1] due to the implicit bound checking. However, Java-applications can also access C/C++ code libraries via the Java Native Interface (JNI). Developers may use JNI to incorporate own C/C++ li- braries into the program code, e.g., due to performance reasons. Moreover, many C libraries are mapped by default to fixed memory addresses in the program memory space. Due to the inclusion of C/C++ libraries, the security guarantees provided by the Java programming language do not hold any longer. In partic- ular, Tan and Croft [31] identified various vulnerabilities in native code of the JDK (Java Development Kit). 2.2 Android Security Mechanisms Discretionary Access Control (DAC). The DAC mechanism is inherited from Linux, which controls access to files by process ownership. Each running process (i.e., subject) is assigned a UserID, while for each file (i.e., object) access rules are specified. Each file is assigned access rules for three sets of subjects: user, group and everyone. Each subject set may have permissions to read, write and execute a file. Sandboxing. Sandboxing isolates applications from each other and from system resources. System files are owned by either the ���system��� or ���root��� user, while other applications have own unique identifiers. In this way, an application can only access files owned by itself or files of other applications that are explicitly marked as readable/writable/executable for others. Permission Mechanism. The permission mechanism is provided by the middleware layer of Android. A reference monitor enforces mandatory access control (MAC) on ICC calls. Security sensitive interfaces are protected by stan- dard Android permissions such as PHONE CALLS, INTERNET, SEND SMS meaning that applications have to possess these permissions to be able to per- form phone calls, to access the Internet or to send text messages. Additionally, applications may declare custom types of permission labels to restrict access to own interfaces. Required permissions are explicitly specified in a Manifest file and are approved at installation time based on checks against the signatures of the applications declaring these permissions and on user confirmation. At runtime, when an ICC call is requested by a component, the reference monitor checks whether the application of this component possesses appropriate 1 Binder in Android is a reduced custom implementation of OpenBinder [21]