Towards Taming Privilege-Escalation Attacks on Android

Sven Bugiel1, Lucas Davi1, Alexandra Dmitrienko3, Thomas Fischer2,Ahmad-Reza Sadeghi1,3, Bhargava Shastry3

1CASED/Technische Universitat Darmstadt, Germany{sven.bugiel,lucas.davi,ahmad.sadeghi}@trust.cased.de

2Ruhr-Universitat Bochum, Germanythomas.fischer@rub.de

3Fraunhofer SIT, Darmstadt, Germany{alexandra.dmitrienko,ahmad.sadeghi,bhargava.shastry}@sit.fraunhofer.de

Abstract

Android’s security framework has been an appealing sub-ject of research in the last few years. Android has beenshown to be vulnerable to application-level privilege esca-lation attacks, such as confused deputy attacks, and morerecently, attacks by colluding applications. While most ofthe proposed approaches aim at solving confused deputy at-tacks, there is still no solution that simultaneously addressescollusion attacks.

In this paper, we investigate the problem of designing andimplementing a practical security framework for Android toprotect against confused deputy and collusion attacks. Werealize that defeating collusion attacks calls for a rathersystem-centric solution as opposed to application-dependentpolicy enforcement. To support our design decisions, weconduct a heuristic analysis of Android’s system behavior(with popular apps) to identify attack patterns, classify dif-ferent adversary models, and point out the challenges to betackled. Then we propose a solution for a system-centric andpolicy-driven runtime monitoring of communication chan-nels between applications at multiple layers: 1) at the mid-dleware we control IPCs between applications and indirectcommunication via Android system components. Moreover,inspired by the approach in QUIRE, we establish semanticlinks between IPCs and enable the reference monitor to ver-ify the call-chain; 2) at the kernel level we realize mandatoryaccess control on the file system (including Unix domainsockets) and local Internet sockets. To allow for runtime,dynamic low-level policy enforcement, we provide a callbackchannel between the kernel and the middleware. Finally, weevaluate the efficiency and effectiveness of our framework onknown confused deputy and collusion attacks, and discussfuture directions.

1. Introduction

Google Android [1] has become one of the most popularoperating systems for various mobile platforms [23, 3, 31]with a growing market share [21]. Concerning security andprivacy aspects, Android deploys application sandboxingand a permission framework implemented as a referencemonitor at the middleware layer to control access to systemresources and mediate application communication.

The current Android business and usage model allowsdevelopers to upload arbitrary applications to the Androidapp market1 and involves the end-user in granting permis-sions to applications at install-time. This, however, opensattack surfaces for malicious applications to be installed onusers’ devices (see, for instance, the recent DroidDreamTrojan [6]).

Since its introduction, a variety of attacks have been re-ported on Android showing the deficiencies of its securityframework. Of particular interest and importance in this con-text are the so-called application-level privilege escalationattacks which are the main focus of this paper.

Privilege escalation attacks at application-level. An-droid’s security framework (enforcing sandboxing and per-mission checks) is not sufficient for transitive policy en-forcement allowing privilege escalation attacks as shownby the recent attacks [16, 12, 20, 35]. Prominent examplesare confused deputy and collusion attacks. Confused deputyattacks [26] concern scenarios where a malicious applicationexploits the vulnerable interfaces of another privileged (butconfused) application2. On the other hand, collusion attacks

1One can register as an Android developer by only paying a fee of $25.Afterwards, developers are free to publish applications on the Androidmarket.

2These attacks range from unauthorized phone calls [16] and text mes-sage sending [12] to illegal toggling of WiFi or GPS service state [20].

concern malicious applications that collude to combine theirpermissions, allowing them to perform actions beyond theirindividual privileges. Colluding applications can communi-cate directly [28], or exploit covert or overt channels in theAndroid core system components [35]. Moreover, applica-tions can launch privilege escalation attacks by exploitingkernel-controlled channels and completely bypass the mid-dleware reference monitor. Examples for such attacks areconfused deputy attacks over a locally established Internetsocket connection, or collusion attacks over the file system[12, 35]. Hence, one needs protection at both abstractionlayers: namely the middleware and the Linux kernel.

Security extensions to Android and problems. Theproblem of application-level privilege escalation attacks hasbeen investigated in the last few years, and various securityextensions and enhancements to Android have been pro-posed such as Kirin [16, 17], TaintDroid [14], Saint [33],QUIRE [13], IPC Inspection [20] to name some. However,as we will discuss in further detail (cf. Section 8), none of theexisting approaches satisfactorily addresses both confuseddeputy and collusion attacks. While the existing solutionsare either static or mostly delegate the policy enforcement toapplications, we realize that tackling collusion attacks callsfor a system-centric solution, not dependent on applications.Moreover, previous solutions suffer from other deficienciessuch as incompatibility to legacy applications (requiring toover-privilege some applications), or inefficiency.

Our goal and contributions. We investigate the problemof building a security framework for Android to protect itagainst confused deputy and collusion attacks. We aim fora general framework which can capture all variations ofapplication-level privilege attacks, as opposite to previousworks targeting attack subclasses. To support our designdecisions, we conducted a heuristic analysis of the runtimebehavior of Android while running many popular applica-tions to observe and identify possible attack patterns. Wepoint out the related challenges towards tackling this prob-lem, and discuss the trade-offs with respect to other majorexisting solutions some of which could be integrated in ourframework to improve our solution. In particular, our contri-butions are the following:

• Security Framework. We present the design and im-plementation of a security framework to detect andprevent confused deputy and collusion attacks. Forthis, we extend Android’s reference monitor concept atboth the middleware and the kernel level as follows:1) runtime monitoring on direct IPC calls betweenapplications and indirect communication through An-droid system components. Inspired by the approachin QUIRE [13] we establish a semantic link between

IPC calls that are checked at runtime by our monitor toidentify call-chains to protect against confused deputyattacks (caused by intents); 2) kernel-level MandatoryAccess Control (MAC) on the file system (files, Unixdomain sockets) and Internet sockets; 3) a runtime inter-action between our security extensions to the Androidmiddleware and the kernel-level MAC, allowing fordynamic runtime policy mapping from the middlewareto the kernel.

• Policy enforcement. Our policy enforcement is system-centric and uses an appropriate high-level policy lan-guage inspired by VALID [4] at the middlewarelayer. At the kernel level, we have adapted TOMOYOLinux [25] to the Nexus One smartphone. Although TO-MOYO can intercept system calls and enforce MAC atthe kernel level, it isn’t aware of contextual informationavailable to the Android middleware (e.g., permissionsthat Android applications possess) in order to take thecorrect decision. To bridge the gap between policyenforcement at the middleware layer and TOMOYO,we dynamically map the policies of the middleware toTOMOYO.

• Performance and effectiveness. Our reference imple-mentation has a negligible performance overhead notnoticeable to the user. We evaluated our implemen-tation on a Nexus One development phone with 50(popular) applications from the Android Market and25 users (students). Note that in contrast to [15, 19]we perform our evaluation manually at runtime3, andhence, 50 applications are already sufficient for ourpurposes. We successfully evaluated our frameworkagainst application-level privilege escalation attackspresented in [16, 12, 20, 35]. In contrast to exist-ing solutions, our implementation detects all of theseattacks including the sophisticated attacks of Sound-comber [35] and an attack launched through locallyestablished Internet connection [12]. Finally, we dis-cuss and evaluate the possible problems, such as the rateof attack detection and falsely denied communication.

Outline. The remainder of this paper is organized as fol-lows: After we recall the Android architecture in Section 2,we introduce the general problem of privilege escalationattacks, present our adversary model and assumptions inSection 3. In Section 4, we present the architecture of oursecurity framework, describe the graph-based system repre-sentation used in our framework, and provide a graph-baseddefinition of privilege escalation attacks. Section 5 is de-voted to defining a security policy for our framework. In

3Note that automated testing of mobile phone applications has beenshown to exhibit a very low execution path coverage and is thus not suitablefor our purposes [22].

Android Runtime Native libs

Application Framework

Dalvik VM Java libs

Default (core) apps Third party apps

Linux kernel

Process Manager Drivers

File System Network

App A

MAC

DAC

App B

DAC

Network sockets

File system or default Linux IPC

ICC

Application layer

Middleware layer

Kernel layer

a) b)

Figure 1. Android internals: (a) Android software stack; (b) Possible communication channels

Section 6, we present the implementation of our frameworkwhose effectiveness and performance we evaluate in Sec-tion 7. Finally, we elaborate on related work in Section 8,and conclude in Section 9.

2. Android

In this section we briefly highlight the internals of the An-droid architecture and recall its major security mechanisms.

Android Software Stack. Android is an open source soft-ware stack for mobile devices. It builds on top of a Linuxkernel and includes a middleware framework and an appli-cation layer (as depicted in Figure 1a). The Linux kernelprovides basic system services to upper layers, such as pro-cess isolation and scheduling, file system support, devicedrivers and networking. The middleware layer includes theDalvik Virtual Machine (DVM), Java and native libraries,and provides system services, such as the application lifecycle management. Further, it provides a Mandatory AccessControl system for application communication. On top, theAndroid application layer includes pre-installed and thirdparty applications. Android applications are mainly writtenin Java, but may incorporate C/C++ code through the JavaNative Interface (JNI). Further, applications basically con-sist of components, where Android provides four basic kindsof components: Activities, Services, Content Providers andBroadcast Receivers. Activities are associated with a userinterface, Services implement functionalities of backgroundprocesses, Content Providers are SQL-like databases, andBroadcast Receivers serve as application mailboxes for eventnotifications.

Application Communication Channels. Possible com-munication channels are shown in Figure 1b. Typically,Android applications communicate through a standard mech-anism provided by the middleware, namely a Binder-basedlightweight Inter-Process Communication (IPC) channel.

Binder IPC calls occur at the granularity of applicationcomponents. Thus, the resulting application communica-tion is often referred to as inter-component communication(ICC) [18] to differentiate it from IPCs at the kernel level.To establish an ICC channel, application components send aspecial message called Intent. Intents typically encapsulatedata that describe the task to perform (e.g., launch activity).

Besides ICC, applications may communicate over chan-nels that bypass Android’s middleware, but are controlled bythe underlying Linux kernel. For instance, communicationcan be established via Linux’s standard IPC mechanisms(e.g., Unix domain sockets, files) or via Internet sockets.Currently, only TrustDroid [9] is able to provide a meansto enforce Mandatory Access Control to prevent communi-cation between applications over these channels. However,TrustDroid attempts to solve the problem of domain isola-tion in a corporate context and is not intended as a solutionagainst privilege escalation attacks.

Android Sandboxing. The underlying Linux kernel en-forces process isolation and discretionary access control toresources (files, devices) by user ownership. To sandbox ap-plications, every application instance in Android is assigneda unique user identifier (UID), while system resources areowned by either the system or root user. Applications canonly access their own files, or files that are explicitly definedas world-wide readable.

Android Permission Framework. Security sensitive re-sources such as a phone call interface, Internet access or usercontacts database are protected by permissions: namely se-curity labels that are defined by the Android system. The listof standard Android permissions contains 110 items4 [24].Most security sensitive resources of Android are provided bya system application called Android. Application develop-ers must declare which permissions are required to properly

4Although Android offers many different kinds of permissions, only afew of them are actively used [2].

Application-level privilege escalation

attacks Confused

deputy attacks

Internet sockets [12]

ICC [16,20]

Colluding applications

Indirect communication

Direct communication

Internet sockets ICC

File system [35]

System components [35]

Addressed by previous research (Quire, IPC Inspection)

Figure 2. Classification of application-level privilege escalation attacks

execute the application. Moreover, they may define new per-missions in order to protect access to sensitive applicationinterfaces. Both newly defined and required permissionsare included in a Manifest file, which is part of an appli-cation’s installation package. At install time, applicationsrequest the necessary permissions from the user. The usercan either grant all the requested permissions, or abort theinstallation process. Once granted, application permissionscannot be changed. Further, Android’s middleware layerenforces Mandatory Access Control (MAC) on ICC calls.Android’s reference monitor checks permission assignmentsat runtime and denies ICC calls in case the caller does nothave the required permissions.

Exceptionally, several permissions (such as INTERNET,BLUETOOTH, WRITE EXTERNAL STORAGE) are notcontrolled by Android reference monitor, but are mappedonto Linux groups and are enforced by a low-level accesscontrol of Linux.

3. Problem Description

In the following, we propose a classification ofapplication-level privilege escalation attacks and define ouradversary model, requirements and assumptions.

3.1. Attack Classification and Adversary Model

We classify application-level privilege escalation attacksinto two major classes as depicted in Figure 2: (i) confuseddeputy attacks and (ii) attacks by colluding applications.

The first class concerns malicious applications (underthe adversary’s control) leveraging unprotected interfacesof a benign application. Recent research results show thatconfused deputy vulnerabilities are common in both thirdparty applications [12, 20] and Android default applicationssuch as Phone [16], DeskClock, Music, and Settings [20].Further, confused deputy attacks can be classified based on

the channel used for privilege escalation i.e., either ICC-based [16, 20] or socket-based [12].

The second class concerns malicious applications thatcollude to merge their permissions and gain a permissionset which has not been approved by the user. For instance,in the Soundcomber [35] attack, one application has thepermission to record audio and monitor the call activity,while a second one owns the Internet permission. Whenboth applications collude, they can capture the credit cardnumber (spoken by the user during a call) and leak it to aremote adversary. In general, colluding applications cancommunicate either directly, e.g., by establishing direct ICCchannels, or via a locally established socket connection,or indirectly, e.g., by sharing files or through overt/covertchannels in system components of Android (as performedby Soundcomber [35]).

We consider a scalable adversary model with the follow-ing types of adversaries: WeakAdversary is able to launchknown5 confused deputy attacks over ICC channels. TheBasicAdversary can launch all kinds of confused deputyattacks, including unknown attacks and attacks over Internetsockets. AdvancedAdversary can launch any confuseddeputy attack and also (unknown) collusion attacks that oc-cur via direct ICC calls. Finally, StrongAdversary canlaunch any privilege escalation attack (at application-level),including collusion attacks that are performed via indirectcommunication, e.g., by sharing files, through Internet con-nection, or through channels established in system compo-nents such as Android.

Note that previous research works [33, 13, 20] aim attackling only the problem of unknown confused deputy at-tacks over ICC channels, while we aim to work towardsa framework that addresses all types of attacks mentionedabove.

5Obviously, known attacks can be fixed, however, this adversary targetsa policy-based approach offering hot fixes. Note that, remote app kill is notan appropriate solution against this adversary, as confused deputies are notmalicious, and even system apps have been shown to suffer from confuseddeputy vulnerabilities [20].

3.2. Objectives and Requirements

Ideally, we aim to address the StrongAdversary model,and discuss in Section 7 that there are several challengesto tackle when designing and implementing a frameworkwhich is both general and fine-grained at the same time.Hence, there is usually a trade-off between attack coverageand granularity of system analysis and policy enforcement.Too coarse-grained analysis may result in negative effects,e.g., in false positives, thereby limiting the usability, whereasattack-specific solutions are obviously limited and may failin defeating other attacks in realistic scenarios. Further,the intuitive idea of combining the existing attack-specificprotection mechanisms may not suffice either, as those maynot be compatible with each other and will likely inducesignificant cumulative performance overhead.

To address this challenge, we require a configurableframework which is flexible and can be adjusted to meet dif-ferent trade-offs between security and usability. In particular,we require a solution which can be configured to be effectivein WeakAdversary, BasicAdversary, AdvancedAdver-sary and StrongAdversary models depending on the re-quirements imposed by the underlying scenario. We furtherrequire (i) a system-centric protection because delegatingthe policy enforcement to applications is risky since the ap-plications themselves might be either vulnerable or evenmalicious (given the huge number of applications availableon the market), (ii) legacy compatibility since recompilationof (many or even all) applications in the Android marketwould be impractical, and (iii) low performance overheadsince in mobile usage scenarios, the imposed performanceoverhead due to security mechanisms should not affect us-ability.

3.3. Assumptions

We make the following assumptions with regard to ourTrusted Computing Base (TCB): we assume that the Linuxkernel and Android’s middleware are not malicious. More-over, we assume that default Android applications are notmalicious6, but they may suffer from confused deputy vul-nerabilities. Further, the Android application may sufferfrom design deficiencies that allow malicious applications toestablish indirect communication links (see e.g., [35]).

4. Framework Architecture

After providing a short overview of our security archi-tecture, we will describe in detail the involved componentsin our architecture and how they interact with each other.

6This is reasonable, since in general one may have more trust in genuinevendors (e.g., Google, Microsoft, and Apple) not to maliciously attackend-users.

Finally, we introduce the graph-based system representationof our architecture.

4.1. Overview

Our security framework performs runtime monitoring andanalysis of communication links across applications in orderto prevent potentially malicious communication based on adefined system-centric security policy. We maintain a systemstate that includes the applications installed on the platform,files, Unix sockets and Internet sockets, as well as directand indirect communication links established among appli-cations. Direct communication links are ICC calls, whileindirect channels are, e.g., shared files. Our extension isinvoked when applications attempt to establish an ICC con-nection, access files or connect to sockets. The frameworkvalidates whether the requested operation can potentiallybe exploited for a privilege escalation attack (based on theunderlying security policy).

4.2. Component Interaction

The architecture of our framework is shown in Figure 3.Generally, it builds on our previous work, a framework calledXManDroid [8] that enhances Android’s middleware. In thiswork, we extend XManDroid with a kernel-level module.In the following paragraphs, we shall describe the compo-nents in our architecture and their interaction in the follow-ing use cases: ICC call handling (steps 1-11), application(un)installation (steps a-b), file/socket creation (steps α - γ),file/socket read/write access (steps i-iv), and policy installa-tion (steps I-III).

ICC call handling. At runtime, all ICC calls are inter-cepted by the Android ReferenceMonitor (step 1). It ob-tains information about permissions from the AndroidPer-missions database (step 2) and validates permission assign-ments. If ReferenceMonitor allows an ICC call to pro-ceed, it invokes DecisionEngine (step 3) to ensure that thecommunication additionally complies with the underlyingsystem security policy. DecisionEngine first requests fora record corresponding to this particular ICC call from thePolicyDecisions database (step 4). If a matching recordis found, it means that a previously made decision can beapplied. Otherwise, DecisionEngine makes a fresh deci-sion based on inputs from AndroidPermissions (step 5),SystemPolicy (step 6) and SystemView (step 7). In par-ticular, the SystemView is represented as a graph, whereentities such as applications are represented as nodes, andtheir established communication links as edges (more detailsare provided in Section 4.3). Subsequently, the resultingdecision is stored in the PolicyDecisions database (step 8),and if it is positive, SystemView is updated to reflect the

New components Unmodified components Modified components

Application B

Application Layer

Application A

Android Middleware

a

b

Package Manager

1 11

10 3

Reference Monitor

Android Permissions

2

5

7

9 8 II

Polic

y In

stal

ler

6 I

4 Decision Engine

Linux Kernel

System View

III

File System/Internet Sockets

Kernel MAC C

reat

e/ D

elet

e

File

/ So

cket

Rea

d /

Wri

te

File

/ S

ock

et

α β

γ

i ii iii

iv

Figure 3. Framework Architecture

fact that a communication link exists among the componentsof applications A and B (step 9). Further, DecisionEngineinforms ReferenceMonitor about the decision it has made(step 10), and ReferenceMonitor either allows (step 11) ordenies the ICC call.

Application (un)installation. The installation procedureinvolves the standard PackageManager of Android. Typ-ically, it extracts the application permissions from theManifest file and stores them in the AndroidPermissionsdatabase (step a). In addition, PackageManager adds anew app into SystemView (step b). Upon application unin-stallation, PackageManager removes all entries of the unin-stalled application from the AndroidPermissions database(step a) and removes the app from SystemView (step b).

Operations on files, Unix domain sockets and Internetsockets. When an application performs a file or Unix do-main socket operation (create, read/write, connect, etc.), ortries to establish a connection over an Internet socket, theoperation is intercepted by KernelMAC: a Mandatory Ac-cess Control (MAC) module in the Linux kernel. When afile/socket is created (step α), KernelMAC updates Sys-temView accordingly (step β) and performs the requestedaction (step γ). Upon request for read access to files, connect-ing to Unix sockets, or connecting to local Internet sockets(step i), KernelMAC looks up its internal policy file to checkif the requested operation can be allowed to proceed. Ifsuch a rule does not exist in its internal policy file, Ker-nelMAC requests a policy decision from DecisionEngine(steps ii and iii), and subsequently denies/grants the opera-tion accordingly (step iv). Furthermore, KernelMAC could

be instructed to cache policy decisions (relayed by Decisio-nEngine) in its internal policy file for future use. Doingso reduces the performance overhead induced by contextswitches between the kernel and the middleware.

Policy installation. PolicyInstaller writes (updates) thesystem policy rules to the SystemPolicy database (step I).Next, it removes all decisions previously made by the Deci-sionEngine, as those may not comply with the new systempolicy (step II). Also, SystemView component is reset toa clean state (step III), i.e., all previously allowed commu-nication links among applications are removed. Note thatSystemView state is only reset upon update of SystemPol-icy and persists across reboots.

Intent tagging. An important feature for fine-grained anal-ysis of communication links that can lead to confused deputyattacks is to establish causal relations between different ICCcalls and/or Intents. Inspired by the solution of QUIRE [13],our framework builds a call-chain of the UIDs in coheringICCs. In contrast to QUIRE, we opted for a system-centriccall-chain. We started to integrate such a mechanism intoAndroid’s Binder code to cover all kinds of IPC. Our firstexperiments demonstrate that such a mechanism is feasibleand can be done efficiently. However, in our current design,we chose an Intent-based approach by automatically taggingnewly created Intents with the UID of the calling application.This information is used by DecisionEngine to re-createthe path in the graph (which is part of the SystemView) thatlead to the current ICC.

4.3. System View Instantiation

Graph-based representation. We opted for a graph-based instantiation of the system state SystemView, wherevertices represent entities such as application sandboxes,system components, files7 and Internet sockets while edgesrepresent the communication and access links (among them).In our design, we record file system access as well as accessto Internet sockets in the graph, as edges inserted between,e.g., a file and an application writing or reading this file.8

Generally, a graph-based representation allows different lev-els of system abstractions: for instance applications can berepresented at the level of application sandboxes, applicationpackages, or application components, while communicationlinks can be seen as directed or undirected edges, thus eitherproviding exact information about the direction of informa-tion or control flows or always assuming a bidirectional flowbetween graph vertices. Hence, we consider the Androidsystem as a graph G consisting of a set V(G) of vertices anda set E(G) of direct edges. An edge e ∈ E(G) is an orderedpair e = (i; j), where i, j ∈ V: i 6= j.

Graph Vertices. We represent applications at the sandboxlevel because applications residing within the same sandboxhave the same privileges, and thus cannot escalate privilegesinside the sandbox9. However, the Android system applica-tion is an exceptional case and requires a more fine grainedrepresentation. It consists of system services and systemcontent providers, which, by design, provide overt as well ascovert channels between applications. For instance, applica-tions can insert data into and read data from system contentproviders such as the contacts database (overt channel), orperform synchronized write-read operations on the settingsof a system service such as the audio manager (covert chan-nel). Thus, Android can mediate communication of otherapplications, and hence we take this into account in ouranalysis.

If represented as a single vertex in the graph, Androidwould cause transitive closure for many vertices becausemany applications access Android (cf. Figure 4a) to getsystem services. However, a finer-grained representationof Android, e.g., at the level of application componentsis challenging because Android system application is real-ized as a monolithic application. To resolve this issue, we

7We do not distinguish files and Unix sockets because Unix domainsockets have much in common with files (e.g., file system address namespace and access permissions) and can be treated in the same way.

8Alternative approaches may, e.g., rely on theorem solvers suchas Prolog (see [16]). However, our early experiments (with tuProloghttp://alice.unibo.it/xwiki/bin/view/Tuprolog/) showed that a Prolog-basedapproach suffers from manageability problems at runtime and inducesuser-notable performance overhead.

9The problem of malware comprising a single application or an appli-cation sandbox is orthogonal to the problem of privilege escalation and isaddressed by previous research, e.g., by Kirin [17].

Sandbox

Communication link

Colluding Apps

C

D

F

A

B E

a) b)

Android C

D

F

A

BE

Android

System Components

Figure 4. (a) Android system app providestransitive closure to other apps; (b) Androidsystem app is split up into system compo-nents (System Services and System ContentProviders)

introduced two important design extensions (discussed inmore details in our technical report [8]): (i) extraction ofthe system content providers and services from the mono-lithic Android and representing them in the system graphas virtual nodes, because they are assigned virtual UIDs (cf.Figure 4b), and (ii) fine-grained policy-based filtering of datain those providers and services (cf. Section 6). Hence, wedefine four types of graph vertices A,S,F , I representingthe set of of application sandboxes, system components, files,and Internet sockets.

Graph Edges. We define the following three types ofedges: (i) ICC calls M, (ii) file access K, and (iii) Inter-net sockets/connectionsH. Note that we represent ICC callsamong two application sandboxes and established Internetconnections as bidirectional edges in the graph.While repre-senting ICC calls with bidirectional edges precludes certainlegitimate communication, this over-approximation is neces-sary. For instance, ICC calls and Internet connections oftenresult in bidirectional data-flows, not observable at our levelof system abstraction. Similarly, pending Intents10 obfuscatethe actual data flow in the system graph, such that they arecurrently not representable with unidirectional edges. Incontrast, the direction of data flow upon (read/write) accessto files, as well as ICC calls to system components can beprecisely distinguished. Edges inM can connect verticesrepresenting application sandboxes A and/or system compo-nents S: ∀e ∈ M: e = (i, j), i, j ∈ A ∪ S, i 6= j. Edgesin K can only connect pairs of vertices, where one vertex isan application sandbox in A and the other one is a file in F(ordered pair representing read/write): ∀e ∈ K: e = (i, j),(i ∈ A, j ∈ F) ∨ (i ∈ F , j ∈ A). Edges that represent In-ternet connections can only connect pairs of vertices, whereone vertex is an application sandbox and the other one is anInternet socket ∀e ∈ H : e = (i, j), i ∈ A, j ∈ I. Figure 5depicts a graph snapshot with all defined types of verticesand edges.

10The sender of an Intent delegates the insertion of payload to anotherapp before sending the Intent.

A

A

A A

Application sandbox

ICC between two apps

A

S

F

F

I

A

A

S

S System component

F File/Unix socket

Internet SocketI

Established Internet connection

Read/write access to files and ICC to system components

Figure 5. System graph representation

Vertex Properties. Each vertex V in the system graph Gis assigned the corresponding properties: a unique identifierU(V ) (i.e., UID for a sandbox, virtual UID for a systemcomponent, path/file name for files and IP address and portfor Internet sockets), and a trust level T (V ) = (true, false)where we currently distinguish two trust levels: ”untrusted”are third party applications, while ”trusted” are default An-droid apps and system components. Moreover, file and In-ternet socket vertices are also considered as trusted. This isbecause files or sockets themselves cannot perform a priv-ilege escalation attack, but may mediate communicationof malicious applications in the same way as trusted sys-tem components. Moreover, application sandboxes featureadditional properties, particularly, names of applications in-cluded in a sandbox (e.g., package names) N (A), a list ofapplication components for each application C(A), and theset of granted permissions P(A) to application A.

Path. A path L(v1, vn) = (e1, e2, ..., en−1) in a graphG between vertices v1 and vn is a sequence of edgese1 = (v1, v2), e2 = (v2, v3), ..., en−1 = (vn−1, vn), wheree1, ...en−1 ∈ E , vi 6= vj for i, j ∈ 1, ..., n. In other words,a path is an acyclic sequence of edges connecting vertices.We define two path properties: (i) a path length, which isdenoted as |L(v1, vn)| = n− 1, and (ii) a set of data D(L)transmitted through the path.

Privilege escalation on the graph. We define patternsof privilege escalation attacks by specifying a set of crit-ical permissions in the system. For instance, gaining ofprivileges allowing both to access the Internet and locationinformation can be defined as an attack pattern correspond-ing to a location tracker. We denote the critical permissionsset by Z . In a confused deputy attack, an unprivileged ap-plication A ∈ A can obtain a critical set of permissionsZ by invoking a privileged application B ∈ A, if thereexists a communication path L(A,B). The privilege esca-lation attack by colluding applications A,B ∈ A can occur,when there is a communication link L(A,B) ∨ L(B,A) be-tween two applications, and each individual set of privilegesP(A) and P(B) does not match the critical set of privileges,

while a union of both does so, i.e., Z* P(B)∧ Z* P(A)∧(Z⊆ (P(A) ∪ P(B))).

5. Policy

Different policy profiles can be created in order to coverdifferent adversary models and user requirements. For in-stance, the following profiles can be specified: Default-Profile, BasicProfile, AdvancedProfile and StrongProfile,that correspond to adversary models WeakAdversary, Basi-cAdversary, AdvancedAdversary and StrongAdversary(defined in Section 3) respectively. DefaultProfile can beactivated by default, in the form of policy rules that helpdefend against known confused deputy attacks occurring viaan ICC channel. Furthermore, policy rules could be definedsuch that they do not result in false positives (confirmedby our evaluation results, Section 7) thereby not affectingusability. This profile can be updated, e.g., by Google, inform of security patches upon discovery of new attacks. Theprofiles BasicProfile, AdvancedProfile and StrongProfilecan be activated by users with higher security requirementswho are willing to tolerate (a small number of) possible falsepositives in favor of increased security. For instance, theseprofiles can be useful in a corporate context, where an enter-prise issues mobile devices to its employees and allows themto use their devices for both private and business purposes.The company’s system administrators may then have thepossibility of generating custom policy profiles that addressthe security requirements of the company.

For expressing policy rules, we define a policy languageinspired by VALID [4], a formal security assurance languagedeveloped for virtualized infrastructure topologies. VALIDhas been shown to be effective when validating policies ongraph based models of virtualized infrastructures [5]. Itexpresses high-level security goals (policy rules in our termi-nology) for such environments in the form of attack states.The language is very suitable for our purposes because it iscapable of expressing operations on graphs, such as infor-mation flow in a graph model of the underlying topology.When mapped to our system representation graph (cf. Sec-tion 4.3), it is used to express system states that describeprivilege escalation attacks. Security goals can then state theinformation flow through edges in the graph that could resultin privilege escalation. VALID describes properties of graphvertices, but is limited in expressing path properties. For ourpurposes, we extended VALID to specify path properties,such as path source, path destination, data transmitted overthe path and so on (cf. Section 4.3).

We illustrate a policy rule to preserve privacy of phonecalls in Figure 6. For instance, we already explained theattack scenario of Soundcomber [35] in Section 3, whichtargets privacy of user phone calls. The rule defines an un-desirable set of permissions that would allow malware to

Section types:A,B : Application sandboxesL(A,B) : Path

Section goals:goal ProtectCallPrivacy(deny) := L.connects(A,B) ∧ L.type(any) ∧ A.trustLevel(

untrusted) ∧ ¬(A.hasPermission(INTERNET) ∧ (A.hasPermission(PHONE STATE) ∨ A.hasPermission(PROCESS OUTGOING CALL)) ∧ B.trustLevel(untrusted) ∧ ¬(B.hasPermission(PHONE STATE) ∨ B.hasPermission(PROCESS OUTGOING CALL)) ∧ B.hasPermission(INTERNET)

Figure 6. A policy rule to defeat attacks ofmalware monitoring phone calls

record phone calls and transfer recorded data to the Internet.Further, it only restricts communication between two appli-cations that do not individually possess the undesirable set ofpermissions, but would obtain it when their permission setsare combined. The applications are not allowed to communi-cate via any of possible communication channels (direct andindirect ICC, file system, or a local Internet connection).

Further examples of policies can be found in Appendix B.

6. Implementation

In this section we present the implementation of our archi-tecture and its main components, as presented in Section 4.2.Our implementation is based on the Android 2.2.1 sources11.

System View. We implemented the system view graph bymeans of the open-source JGraphT12 library, version 0.7.3.The initial system graph is built upon first boot of the de-vice. We use the PackageManager to discover installedapplications during the graph building process. In case ofa sandbox that is shared by several applications, the infor-mation from all these applications with the shared UID ismerged in the corresponding vertex. Vertices that representfiles and Internet sockets are added to the system graph atruntime, at first access request to the file/socket. To keepthe overhead low, we add only world-wide readable/writablefiles to the graph. This is sufficient for our analysis, becauseprivate files cannot be shared by different sandboxes (due tothe Discretionary Access Control of Linux kernel).

To extract system content providers from the monolithicAndroid, we extended the ActivityManager of Android.Usually, the ActivityManager detects and registers all in-stalled content providers in the system during boot-up. Weextended this process such that the ActivityManager insertsa vertex for each of them in the graph via an interface ofSystemView. We pre-install vertices that correspond to

11http://source.android.com12http://www.jgrapht.org/

system services in the graph (as those are known and fixed).We opted not to use Android’s Service Manager that main-tains a list of the registered services, because it does notdistinguish system and third party services. Further, we mod-ified the content providers’ interfaces to prevent colludingapplications from exchanging data over content providers.Each data row in the database is tagged with the UIDs of thewriters. Upon writing data, these tags are updated. Uponreading, our extension to the reading interface verifies foreach read row if the corresponding reader-writer pairs con-stitute a policy violation. If so, the corresponding row isfiltered from the response to the reader before return.

To enforce policy checks within system services, we tageach value of the service with the UID of the writer. Note,in contrast to content providers, values in system servicescan be only overwritten, thus we store the UID of the lastwriter. Tagging of values is implemented as a mapping fromvalue to writer UID. Upon reading of values, we use a similarinterface as for content providers to perform a policy checkif the reading would trigger a policy violation. If so, a nullvalue is returned.

Package Manager. We modified the PackageManagerto update the system graph upon installation or uninstallationof an application package. The installation adds a new vertexfor the new application UID to the graph. In case of sharedUIDs, the information of all applications under this UID aremerged. Application uninstallation causes the removal of thecorresponding vertex. Uninstallation in the case of a sharedUID is slightly more complex, since only the informationadded by the uninstalled application has to be removed. Weimplemented this by removing the corresponding vertex andreconstructing it afterwards with the updated applicationinformation.

Policy Decisions. PolicyDecisions stores a boolean forthe decision result of each checked ICC, file access or socketconnection, i.e., granted or denied. It is implemented as amapping from distinct ICC to decision result. The index ofthe mapping is the unordered tuple {uid caller, uid callee}for each inserted decision. PolicyDecisions is persistentacross system reboots.

Decision Engine. DecisionEngine implements a policychecking algorithm, which determines if a new edge in thesystem graph would complete a path in SystemView, whichmatches a policy rule. The algorithm uses backtracking13 toexplore, in a depth-first search fashion, all paths consistingonly of vertices that match a distinct vertex description in

13Backtracking algorithms incrementally build candidates to the solutionfor the targeted problem and abandon partial candidates, when they detectthat this candidate does not lead to a valid solution.

the same policy rule. This procedure is continued until itfinds a path that matches the policy rule exactly. It furthercompiles the high-level policy rules (written in our adaptionof VALID [4]) into XML (based on a custom XML schema),which is more efficiently parsed during policy checking.

Policy Installer and System Policy. The system policy isimplemented in XML, which is loaded upon system boot orafter an update of the policy, respectively. SystemPolicyis installed or updated via the PolicyInstaller component,which is implemented as a service running in the middlewareas part of the ActivityManager and provides an authenti-cated channel in order to externally update the policy.

Reference Monitor. We modified the default Reference-Monitor of Android (which is a part of ActivityManager) toredirect the control flow to our DecisionEngine wheneveran ICC occurs. In particular, we wrapped the checkCom-ponentPermission function with a new function, which firstcalls the default checkComponentPermission function and incase that it would allow the ICC, it invokes DecisionEngine.To enable the DecisionEngine to make the policy checkon direct ICCs, the wrapper function provides the UIDs ofthe caller and callee of the respective ICC as well as theIntent initiating the ICC to the DecisionEngine. To handlebroadcast Intents, we followed the approach presented in[33, Section 6]. Each sender-receiver pair is checked for apolicy violation and the broadcast receiver list is adaptedaccordingly before sending the broadcast message.

Kernel MAC. To enable mandatory access control at thekernel level, our implementation employs TOMOYO Linux14

v1.8, a path-based MAC implementation available as a kernelpatch. An alternative to TOMOYO is SELinux [29], a type-based MAC implementation available as a Linux SecurityModule (LSM). However, SELinux enforces MAC by meansof type enforcement which typically requires extended fileattributes to be enabled in the filesystem. Since Android’sflash file system (YAFFS2) does not support extended fileattributes by default, using SELinux requires prior file sys-tem modifications. On the other hand, TOMOYO, being apath-based MAC implementation, does not require any filesystem modifications prior to usage. Furthermore, SELinuxis harder to administer on a mobile device due to complexpolicy rules that need to be adapted to meet Android’s secu-rity requirements.

Our choice of TOMOYO over SELinux was primarilymotivated by the fact that the former has a readily availableuser-space interface that can be extended in order to providea feedback channel between the kernel and the middleware;

14http://tomoyo.sourceforge.jp/

the latter lacks such an interface thereby precluding commu-nication between the kernel and the middleware. To enablecommunication between the two layers, we wrote a nativelibrary with access to TOMOYO’s interfaces and compiledit against the Java Native Interface (JNI). In order to enableruntime policy updates, we extended an interface of TO-MOYO which allows it to seek a decision from a supervisor(e.g., our DecisionEngine). Further, to make the Androidmiddleware understand what TOMOYO is asking for andvice-versa, we implemented a parser function in Java. Toenable the middleware to make a decision at runtime, TO-MOYO passes the UID of the process making a system callalong with details pertaining to the call itself, e.g., path of fileto be read. The middleware’s DecisionEngine processesthe request and conveys its decision to TOMOYO.

It is important to note that the TOMOYO kernel bootswith a carefully written security policy catered for Android.This policy file is TOMOYO specific and is loaded in thekernel memory during device boot. On intercepting a systemcall post device boot, TOMOYO inspects its internal policyfile to see if there is a policy rule that allows the system callto proceed normally. If yes, the request is granted withoutquerying the DecisionEngine (in the middleware). If no,TOMOYO queries the DecisionEngine for a decision onthe request made. If the DecisionEngine deems it safe togrant the request, it conveys the same to TOMOYO. Thereare two ways in which the DecisionEngine could relay agrant decision: (1) It could simply request TOMOYO toallow the specific system call to proceed normally, or (2)It could in addition to (1) request TOMOYO to add thedecision to TOMOYO’s policy file. Such a flexibility allowsour framework to reduce the number of context switchesbetween the middleware and the kernel which in turn reducesthe performance overhead that could result from frequentcontext switches.

7. Evaluation

We begin this section with a heuristic study of commu-nication patterns between third party applications that, inpart, motivated our design decisions. Subsequently, we pro-vide test results on effectiveness and performance of ourframework and discuss challenges and problems therein.

Test methodology. As methodology for our evaluation, weopted for manual testing with a group of 25 test users, asautomated testing of mobile phone applications has beenshown to exhibit a very low execution path coverage (ap-proximately 40% in average and only 1% in worst case [22]).With respect to this limitation, we argue that 50 selectedapplications from different market categories (e.g., games orsocial tools) form a representative testing set. The test users’task was to install and thoroughly use the provided apps, to

trigger as much as possible of the apps’ features and withinterleaving installation, uninstallation, and usage.

7.1. Study of 3rd Party Application Communication

We performed a heuristic analysis of the communicationpatterns between third party applications from the AndroidMarket. A graphical representation of our results is given inAppendix C, and at this point, we present our main obser-vations and thereby motivate our design decisions (cf. Sec-tion 4).

File system and socket based communications. Fig-ure 10 in Appendix C depicts the observation that the appli-cations we tested neither share their data with other appli-cations at the file system level, nor communicate with eachother via Unix domain sockets. Consequently, an attack vec-tor that uses files or Unix sockets as communication mediumcould be easily identified making it easier to prevent suchan attack. To effectively prevent this attack vector, a kernel-level MAC is required, since applications can make use ofnative code which circumvents any security mechanisms inAndroid’s middleware (cf. Section 2).

Moreover, since legitimate applications are far less likelyto communicate this way, the rate of falsely denied commu-nications is expected to be low. To illustrate this point, wedeveloped sample apps that use a Unix socket or a file forcommunication and this pattern is clearly distinguishablefrom other applications.

ICC based communication. Our observation regardingICC based communication shows that applications usuallyoperate autonomously and do not have functional interde-pendencies with other applications. Exceptions are customlauncher applications which start the Activities of other appsand apps with a “share with” functionality that receive datafrom other apps for sharing (e.g., Facebook, Twitter etc.)The usual way for apps to share data is (System) ContentProviders.

Our design accurately addresses this communication pat-tern, since (1) it implements a very fine-grained policy en-forcement in the system components, and (2) direct commu-nication between apps, which is the main target of genericsystem policy rules, occurs seldom and if so, with a verydistinct pattern (start Activity or share with).

7.2. Effectiveness

We evaluated the effectiveness of our solution based onthe detection rate of attacks specified in the system policy(i.e., the false negative rate) and the rate of falsely deniedcommunications between applications (i.e., false positive

rate). An ideal solution would provide both a zero false neg-ative and zero false positive rate. Our current instantiationapplies over-approximation of communication links, exceptfor Intents (cf. Section 4.3). This means that it assumes arelation between communication channels where none mightexist, e.g., it has no false negatives but tends to cause falsepositives.

Attack detection rate. To evaluate the detection rate ofprivilege escalation attacks, we developed sample applica-tions that implement the attacks described in [35, 20, 16, 12]and deployed a system policy that contained rules targetingthese attacks (see Table 3 in Appendix B). Our frameworksuccessfully detected all of the above mentioned attacks atICC, socket, and file system level, including all the attackscenarios of Soundcomber [35] launched via covert chan-nels in Android system components and a file based covertchannel.

Falsely denied communication rate. We evaluated withour user test the impact of our security framework on theusability of third party applications. During this test, in ad-dition to the policy rules from the attack detection test, wedeployed generic rules to prevent the leakage of sensitiveinformation like the device location, contacts, or SMS viathe Internet. Moreover, we deployed a singular rule thatallows applications to launch other applications with an In-tent if and only if the Intent does not contain any additionaldata/information (see rule 12 from Appendix B)15.

To our surprise, the results of our tests showed no falsepositives. This is on the one hand counter-intuitive, sincethe policy rules of the AdvancedProfile and the StrongPro-file are rather generic and are indicative of a higher rate offalse positives. On the other hand, this result confirms ourobservations and conclusions on the communication patternsbetween third party applications on Android (cf. Section 7.1).

7.3. Performance

Our solution imposes only a negligible runtime overhead,not perceivable by the user. Tables 1 and 2 present ourmeasurement results. In particular, as Table 1 shows, ourframework performs quite steadily in terms of a very lowstandard deviation; the runtime system call latency is lowconsidering the ratio of cached to uncached decisions. Onlythe overhead on intent messages cannot be optimized throughcaching. However, in our ongoing work we implemented ahigher efficient and faster system-centric ICC call-chainingbased on modifications to the Binder mechanism instead ofonly Intents.

15Note, data-less Intents can be used by the adversaries to establishcovert communication. Thus, StrongProfile should include less genericexceptional rules which, e.g., additionally specify application names.

Type Calls Average Std. dev.(ms) (ms)

Original Reference Monitor runtime for ICCsystem 11003 0.184 2.490DecisionEngine overhead for ICCuncached 312 6.182 9.703cached 10691 0.367 1.930Intents 1821 8.621 29.011DecisionEngine overhead for file readfile read 389 3.320 4.088

Table 1. ICC timing results

Type Average Std. dev.(ms) (ms)

Read access to System Content Providerstotal number of accesses: 591read 10.317 41.224overhead 4.983 36.441Read access to System Servicestotal number of accesses: 87read 8.578 20.241overhead 0.307 0.4318

Table 2. Timing results for system components

On read access to System Content Providers (Table 2), thefiltering of values conflicting with system policy imposes anoverhead of approximately 48%. On read access to SystemServices, the overhead is merely about 2.4% on average.This discrepancy stems from the fact that, on read access toContent Providers, usually multiple reader-writer pairs haveto be checked, while access to System Services involves onlyone reader-writer pair.

7.4. Impact on 3rd party applications’ usability

Although we did not observe any false positives in ourtests, any falsely denied communications must be avoided,because they can have a severe impact on the usability of thesmartphone. Denying applications ICC that was expected tobe successful, most likely renders these application dysfunc-tional. Moreover, application developers do not anticipatethis situation, since installed applications have been grantedall the requisite permissions, and thus often omit exceptionhandling code, causing applications to crash in case theirICC call is denied.

This problem applies to all approaches based on revokingpermissions at post-install time or on denying ICC at run-time, as we will explain in Section 8 on related work. It isparticularly hard to solve for situations where one cannotclearly distinguish between a confused deputy attack anda legitimate user action, e.g., when an app that provides a“share with” functionality receives an Intent to share data orwhen the browser is called to open a particular URL.

In our solution, we strive for minimizing the number offalse positives by (1) decomposing the monolithic Androidinto distinct services and content providers in our systemgraph and (2) by performing a heuristic analysis of the com-munications patterns of applications. The former one facil-itates a more fine-grained policy check on access to datashared via system components, while the latter is used torefine the policy design.

Android Middleware

Linux Kernel

Hardware

App A

Installer

Kirin

Saint

Apex

Reference Monitor

Saint

Apex

Porscha Mediator

App B

Perm. P2 Perm. P3 Perm. P1

CRePE

Dalvik VM

TaintDroid

Sensitive Data

Permission Database

Paranoid Android

SELinux

QUIRE

QUIRE

Static and Offline Analysis Tools

ded

ComDroid

Stowaway

IPC Inspection

AppFence

TrustDroid

TrustDroid

Figure 7. Security extensions for Android

8. Related Work

Figure 7 shows security extensions for Android that havebeen proposed in the past. Since most proposed solutionsrequire changes to Android’s middleware, we highlightedthe main middleware components such as the applicationinstaller, the reference monitor, the permission database, andthe Dalvik virtual machine. Each solution requires extensionto one or more components, as we shall describe in thefollowing paragraphs.

As Figure 7 shows, several security extensions to An-droid’s security framework have been proposed over the lastfew years [16, 17, 33, 36, 30, 14, 11, 32, 34]. However, notall of them target privilege escalation attacks: Porscha [32]provides policy-oriented secure content handling; Apex [30]allows users to selectively grant and deny permissions atinstall time; CRePE [11] enables the enforcement of context-related policies; Paranoid Android (PA) [34] aims to detectviruses and runtime attacks. Finally, several static analysistools have been proposed that mainly aim to detect vulnera-

ble application interfaces [10, 15] or analyze if applicationsfollow the least-privilege principle [19].

Hence, in the following paragraphs, we shall discuss thestrengths and shortcomings of security extensions that areclosest to ours.

Kirin is an extension to Android’s application in-staller [16, 17]. Kirin checks the permissions requestedby applications at install-time. It denies the installation of anapplication if the permissions requested by the applicationencompass a set of permissions that violates a given system-centric policy. The main security goal of Kirin is to mitigatemalware contained within a single application. In addition,the Kirin framework described in [16] also allows identifica-tion of security-critical communication links by analyzingwhich interfaces the new application is authorized to contact.However, due to its static nature, Kirin has to consider all po-tential communication links over the unprotected interfaces.This will stop any application from being installed, since ap-plications can potentially establish arbitrary communicationlinks over the unprotected interfaces. In contrast to Kirin,our framework (1) focuses on real (runtime) communicationlinks rather than potential ones, (2) decides at runtime if thelink (including communications over unprotected interfaces)to be established violates the system policy.

Saint [33] introduces a fine-grained access control modelthat allows application developers to attach security policiesto their applications, in particular, to the application’s in-terfaces. It enforces security decisions based on signatures,configurations and contexts (e.g., phone state or location),while security decisions themselves are enforced both atinstall-time and at runtime. In order to prevent confuseddeputy attacks, developers have to assign appropriate se-curity policies on each interface, i.e., they have to specifywhich permissions/configuration/signature the caller is re-quired to have in order to access an interface. However,if the incentives behind these policies protecting the calleeconflict with the properties of the calling application, ICCis denied leading to the problem of caller malfunction orcrash as explained in Section 7.4. Moreover, since appli-cation developers have to define these policies themselves,they might fail to consider all security threats. Finally, Saintdoes not address malicious developers, who will not deploySaint policies for the obvious reason that they might wantto mount a collusion attack. By contrast, our frameworkdeploys a system-centric solution which is also applied tomalicious colluding applications, and enforces its policies atthe file-system and network layer as well.

QUIRE [13] is a recent Android security extension whichprovides a lightweight provenance system to prevent con-fused deputy attacks via Binder IPC. In order to determinethe originator of a security-critical operation, QUIRE tracksand records the IPC call chain, and denies the request if theoriginating application has not been assigned the correspond-

ing permission. Additionally, QUIRE extends the networkmodule residing in the Android Linux kernel to verify theprovenance of remote procedure calls (RPCs) when they aimto leave the device. However, similar to Saint, QUIRE isapplication-centric-applications forward and propagate theIPC call chain themselves. Due to its application-centricnature, QUIRE cannot prevent colluding applications, be-cause they may drop the IPC call chain and act on their ownbehalf, and hence, circumvent QUIRE’s defense mechanism.Furthermore, the unexpected denial of access by the receiverof the call chain might lead to application dysfunction/crashon the caller’s side (cf. Section 7.4).

IPC Inspection [20] is a very recent work that is similarto QUIRE and tackles confused deputy attacks via BinderIPC. IPC Inspection reduces the permissions of an applica-tion when it receives a message from a less privileged one.In contrast to our framework, IPC Inspection does not re-quire a policy framework, and hence, can prevent unknownattacks without the deployment of appropriate policies. How-ever, IPC Inspection does not provide a solution againstmaliciously colluding applications. Although the receiver’spermissions are reduced to the sender’s permissions, the indi-vidual application instances at the receiver’s side still residein one sandbox and thus are not properly isolated from eachother and can communicate freely. Moreover, IPC Inspec-tion will induce a significant performance overhead, becauseit requires the maintenance of multiple application instanceswith different sets of privileges. An open question hereis: how is permission reduction performed for permissionsthat are controlled by the underlying Linux discretionary ac-cess control (DAC) system rather than Android’s referencemonitor (e.g., Internet or Bluetooth)? Further, applicationsexecuting with an unexpectedly reduced permission set arevery likely to crash (cf. Section 7.4). This issue could betackled over-privileging applications that crash. However,doing so makes the framework incompatible with legacyapplications, while in our framework we only require policyadjustment.

TaintDroid [14] is a framework which detects unautho-rized leakage of sensitive data. TaintDroid exploits dynamictaint analysis in order to label privately declared data witha taint mark, audit on-track tainted data as it propagatesthrough the system, and warn the user if tainted data aimsto leave the system at a taint sink (e.g., network interface).TaintDroid is able to detect data leakage attacks potentiallyinitiated through a privilege escalation attack. However,TaintDroid mainly addresses data flows, whereas privilegeescalation attacks also involve control flows. Its authorsmention that tracking the control flow with TaintDroid willlikely result in much higher performance penalties. More-over, since TaintDroid only detects leakage, it would requiresome policy-based framework on top to distinguish betweenauthorized and malicious data leakage, as done in AppFence

that is discussed below.AppFence [27] builds upon and extends the current Taint-

Droid framework by allowing users to transparently enableprivacy control mechanisms. In particular, AppFence tacklesthe usability problem when permissions are revoked fromapplications, e.g., it provides faked or blank data when appli-cations access content providers they should not be allowedto access. Nevertheless, like TaintDroid, AppFence providesno means to detect privilege escalation attacks beyond dataleakage attacks.

SELinux on Android [36] presents a prototype imple-mentation of SELinux on an Android device. Although thiswork argues for an SELinux-based solution to Android’s se-curity vulnerabilities at the kernel level, it does not attempt toprovide a solution for the same. Furthermore, the prototypepresented in [36] lacks a coordination mechanism betweenthe Linux kernel and the Android middleware. During thecourse of our work, we realized that such a coordinationmechanism is crucial to bridging a semantic gap between thetwo layers: namely Linux kernel and Android middleware.Our TOMOYO-based solution not only proposes a solutionagainst attacks employing kernel-level channels such as filesand sockets, but also enables communication between thekernel and the middleware so that the former can query thelatter in case the former does not have sufficient informationto take a security decision at runtime.

TrustDroid [9] is a recent security extension to Androidthat aims to provide domain isolation, typically between abusiness domain and a private domain. Thus, TrustDroidbuilds on a pre-determined basis for classifying applicationsat install time. On the other hand, our work offers a moregeneric solution against privilege escalation attacks. Sincethere is no pre-determined basis to classify applications as inthe case of TrustDroid, access control in our solution is moredynamic (requiring decisions to be made on the basis ofapplication behaviour e.g., files read/written), and is carriedout at run-time.

Orthogonal Security Frameworks. The framework wepresented in this paper is built upon former research on oper-ating system security. First, our work relates to stack inspec-tion (e.g., [37]), a security mechanism that enforces accessdecisions by inspecting the call chain of a request. This isalso along the lines of QUIRE [13]; our framework tracks thecall chain in a system-centric way. Further, our framework isrelated to the chinese-wall (CW) security model [7]: If a sub-ject aims to access an object then the CW model grants/denythe access based on what the subject has already accessedin the past. The overall goal is to prevent information flowbetween objects sharing the same conflict of interest class.Similarly, our framework enforces access decisions on whatthe IPC caller accessed in the past.

9. Conclusion

In this paper, we address the problem of confused deputyand collusion attacks on Android. We propose the designand implementation of a practical security framework forAndroid that monitors application communication channelsin Android’s middleware and in the underlying Linux kernel(namely, IPC, file system, Unix domain and Internet sockets)and ensures that they comply with a system-centric secu-rity policy. We propose several adversary models, defineconfused deputy and collusion attacks based on a graph-based representation of our security framework and analyzetypical communication patterns of Android applications bymeans of a heuristic study. Our design accurately addressesour observations, as it implements a very fine-grained pol-icy enforcement in the system components, which are theprimary means for applications to share data. Inspired byQUIRE[13], we integrate Intent tagging techniques into oursystem (but in a system-centric way) in order to increasethe precision of our analysis. Moreover, a novelty of ourprototype is the runtime interaction between our securityextensions to the Android middleware and TOMOYO Linux,allowing for dynamic runtime policy mapping from the se-mantically rich middleware to the kernel. Our evaluationresults show that our framework is efficient, effective andusable. It can prevent recently published privilege escalationattacks [16, 12, 20, 35], including sophisticated attacks suchas Soundcomber [35] launched via covert channels in theAndroid system components.

For our future work, we plan extensive user tests of oursecurity framework using a large number of applicationsfrom the Android market. Furthermore, we aim to continueour current work on performing system-wide ICC call-chainverification at the Binder level. Finally, we would like toexamine how we can integrate SELinux into our securityframework.

Acknowledgments

The first author has been supported by the EuropeanUnion’s Seventh Framework Programme (FP7/2007-2013)under grant agreement n◦257243 (TClouds project: http://www.tclouds-project.eu).

References

[1] Google Android. http://www.android.com/.[2] D. Barrera, H. G. Kayacik, P. C. van Oorschot, and A. So-

mayaji. A methodology for empirical analysis of permission-based security models and its application to Android. In 17thACM conference on Computer and communications security(CCS), 2010.

[3] D. Bell. Samsung Galaxy Tab Android tablet goes offi-cial. http://news.cnet.com/8301-17938_105-20015395-1.html, 2010.

[4] S. Bleikertz and T. Groß. A virtualization assurance languagefor isolation and deployment. In IEEE International Sym-posium on Policies for Distributed Systems and Networks(POLICY), 2011.

[5] S. Bleikertz, T. Groß, M. Schunter, and K. Eriksson. Auto-mated information flow analysis of virtualized infrastructures.In 16th European Symposium on Research in Computer Se-curity (ESORICS). Springer, 2011.

[6] T. Bradley. DroidDream becomes Android market nightmare.http://www.pcworld.com/businesscenter/article/221247/droiddream_becomes_android_market_nightmare.html, 2011.

[7] D. F. Brewer and M. J. Nash. The Chinese Wall securitypolicy. IEEE Symposium on Security and Privacy, 1989.

[8] S. Bugiel, L. Davi, A. Dmitrienko, T. Fischer, and A.-R.Sadeghi. XManDroid: A new Android evolution to mitigateprivilege escalation attacks. Technical Report TR-2011-04,Technische Universitat Darmstadt, 2011.

[9] S. Bugiel, L. Davi, A. Dmitrienko, S. Heuser, A.-R. Sadeghi,and B. Shastry. Scalable and lightweight domain isolationon Android. In Proceedings of the 1st ACM workshop onSecurity and Privacy in Smartphones and Mobile Devices(SPSM), 2011.

[10] E. Chin, A. P. Felt, K. Greenwood, and D. Wagner. Analyzinginter-application communication in Android. In 9th AnnualInternational Conference on Mobile Systems, Applications,and Services (MobiSys), 2011.

[11] M. Conti, V. T. N. Nguyen, and B. Crispo. CRePE: Context-related policy enforcement for Android. In 13th InformationSecurity Conference (ISC), 2010.

[12] L. Davi, A. Dmitrienko, A.-R. Sadeghi, and M. Winandy.Privilege escalation attacks on Android. In 13th InformationSecurity Conference (ISC), 2010.

[13] M. Dietz, S. Shekhar, Y. Pisetsky, A. Shu, and D. S. Wallach.QUIRE: Lightweight provenance for smartphone operatingsystems. In 20th USENIX Security Symposium, 2011.

[14] W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung, P. Mc-Daniel, and A. N. Sheth. TaintDroid: An information-flowtracking system for realtime privacy monitoring on smart-phones. In 9th USENIX Symposium on Operating SystemsDesign and Implementation (OSDI), 2010.

[15] W. Enck, D. Octeau, P. McDaniel, and S. Chaudhuri. A studyof Android application security. In 20th USENIX SecuritySymposium, 2011.

[16] W. Enck, M. Ongtang, and P. McDaniel. Mitigating Androidsoftware misuse before it happens. Technical Report NAS-TR-0094-2008, Pennsylvania State University, 2008.

[17] W. Enck, M. Ongtang, and P. McDaniel. On lightweight mo-bile phone application certification. In 16th ACM conferenceon Computer and communications security (CCS), 2009.

[18] W. Enck, M. Ongtang, and P. McDaniel. UnderstandingAndroid security. IEEE Security and Privacy, 7, 2009.

[19] A. P. Felt, E. Chin, S. Hanna, D. Song, and D. Wagner. An-droid permissions demystified. In 18th ACM Conference onComputer and Communication Security (CCS), 2011.

[20] A. P. Felt, H. Wang, A. Moshchuk, S. Hanna, and E. Chin.Permission re-delegation: Attacks and defenses. In 20thUSENIX Security Symposium, 2011.

[21] Gartner Inc. http://www.gartner.com/it/page.jsp?id=1689814, 2011.

[22] P. Gilbert, B.-G. Chun, L. Cox, and J. Jung. Automatingprivacy testing of smartphone applications. Technical ReportCS-2011-02, Duke University, 2011.

[23] GIZMODO. http://gizmodo.com/5568458/toshiba-ac100-netbook-runs-android-and-has-massive-seven-days-of-standby-battery-life, 2010.

[24] Google. The Android developer’s guide - Android Manifestpermissions. http://developer.android.com/reference/android/Manifest.permission.html, 2010.

[25] T. Harada, T. Horie, and K. Tanaka. Task oriented manage-ment obviates your onus on Linux. In Linux Conference,2004.

[26] N. Hardy. The confused deputy: (or why capabilities mighthave been invented). SIGOPS Oper. Syst. Rev., 22, 1988.

[27] P. Hornyack, S. Han, J. Jung, S. Schechter, and D. Wether-all. These aren’t the Droids you’re looking for: RetrofittingAndroid to protect data from imperious applications. InProceedings of the 18th ACM conference on Computer andcommunications security (CCS). ACM, 2011.

[28] C. Marforio, F. Aurelien, and S. Capkun. Application col-lusion attack on the permission-based security model andits implications for modern smartphone systems. TechnicalReport 724, ETH Zurich, 2011.

[29] National Security Agency. Security-Enhanced Linux. http://www.nsa.gov/research/selinux.

[30] M. Nauman, S. Khan, and X. Zhang. Apex: Extending An-droid permission model and enforcement with user-definedruntime constraints. In 5th ACM Symposium on Information,Computer and Communications Security (ASIACCS), 2010.

[31] Notion Ink. Adam Tablet. http://www.notionink.in/.

[32] M. Ongtang, K. Butler, and P. McDaniel. Porscha: Policyoriented secure content handling in Android. In 26th AnnualComputer Security Applications Conference (ACSAC), 2010.

[33] M. Ongtang, S. McLaughlin, W. Enck, and P. McDaniel.Semantically rich application-centric security in Android.In 25th Annual Computer Security Applications Conference(ACSAC). IEEE Computer Society, 2009.

[34] G. Portokalidis, P. Homburg, K. Anagnostakis, and H. Bos.Paranoid Android: Versatile protection for smartphones. In26th Annual Computer Security Applications Conference(ACSAC), 2010.

[35] R. Schlegel, K. Zhang, X. Zhou, M. Intwala, A. Kapadia,and X. Wang. Soundcomber: A Stealthy and Context-AwareSound Trojan for Smartphones. In 18th Annual Network andDistributed System Security Symposium (NDSS), 2011.

[36] A. Shabtai, Y. Fledel, and Y. Elovici. Securing Android-powered mobile devices using SELinux. IEEE Security andPrivacy, 8(3), 2010.

[37] D. S. Wallach and E. W. Felten. Understanding Java stackinspection. In IEEE Symposium on Security and Privacy,1998.

Appendix A List of tested applications

The Android applications that we tested are the follow-ing: Android System Info, Angry Birds, Android Script-ing Environment, Blast Monkeys, Bluetooth File Transfer,Bubbles, Cheech and Chong, Chess Free, ColorNote, Com-pass, Contact Adder, Daum Maps, Documents To Go, ESFile Explorer, Facebook, Fede Launcher, First Aid, fring,GO Contacts, Google Chrome to Phone, Google Goggles,Google Plus, Google Sky Map, Google Talk, Google Trans-late, Hello Kitty, Hopstop, HowStuffWorks, Human BodyFacts, Jewels, K9 Mail, last.fm, Meebo, Mobile Andrio, Mu-sical Lite, Offi, Opera Mini, PagesJaunes, Paper Toss, QikVideo, ESPN ScoreCenter, Talking Tom, Task Manager, TheThree Stooges, Time2Hunt, Twitter and Urban Dictionary.

Appendix B System Policy

In the following we provide policy rules applied for test-ing. These rules are grouped into five categories: Default-Rules, BasicRules, AdvancedRules, StrongRules andExceptionalRules. DefaultProfile includes policy rules ofcategory DefaultRules, BasicProfile includes policy rulesof category DefaultRules and BasicRules, AdvancedPro-file includes rules of category DefaultRules, BasicRulesand AdvancedRules, while StrongProfile includes policyrules of all categories. ExceptionalRules are exceptionalcases from more general rules defined in the system.

We informally describe each rule in Table 3 and furtherprovide definition of these rules in the policy language (Fig-ure 8).

Appendix C Communication graphs

Figure 9 illustrates visualization of the ICC based com-munication among third party apps and the Android systemduring our user tests. Figure 10 visualizes the file systemand socket accesses by third party apps during testing.

Default rules(1) A third party application that has no permission CALL PHONE can invoke Phone system application only if data transmitted contains

android.intent.action.DIAL parameter (that enforces user confirmation)[16]

(2) A third party application that has no WAKE LOCK permission must not be able to invoke DeskClock system application to play analarm

[20]

(3) A third party application that has no WAKE LOCK permission must not be able to invoke Music system application to play music [20](4) A third party application that has no CHANGE WIFI STATE permission must not be able to invoke Settings system application to

toggle WiFi state[20]

(5) A third party application that has no ACCESS FINE LOCATION permission must not be able to invoke Settings system application totoggle GPS location state

[20]

(6) A third party application that has no BLUETOOTH ADMIN permission must not be able to invoke Settings system application totoggle Bluetooth state

[20]

Basic rules(7) A third party application that has no SEND SMS permission must not be able to contact Android Scripting Environment (ASE) appli-

cation[12]

Advanced rules(8) A third party application with permission ACCESS FINE LOCATION must not communicate to a third party application that has

permission INTERNET(9) A third party application that has permission READ CONTACTS must not communicate to a third party application that has permission

INTERNET(10) A third party application that has permission READ SMS must not communicate to a third party application that has permission

INTERNETStrong rules

(11) A third party application that has permissions RECORD AUDIO and PHONE STATE or PROCESS OUTGOING CALLS must notdirectly or indirectly communicate to a third party application with permission INTERNET

[35]

Exceptional rules(12) A third party application is allowed to start a system or a third party applications by sending an Intent, if this Intent does not include

any additional information

Table 3. Policy rules applied during testing

Section types:A,B: Application sandboxesL: Path

Section goals:goal ProtectDialer(deny) := L.hasSource(A) ∧ L.hasDestination(B) ∧ L.type(ICC.direct) ∧ ¬(L.hasActionString(android.internet.action.DIAL)) ∧ A.trustLevel(untrusted) ∧ ¬

(A.hasPermission(CALL PHONE)) ∧ B.trustLevel(trusted) ∧ B.name(com.android.phone)

goal ProtectDeskClock(deny) := L.hasSource(A) ∧ L.hasDestination(B) ∧ L.type(ICC.direct) ∧ L.hasActionString(com.android.deskclock.ALARM ALERT) ∧ L.hasExtraData(intent.extra.alarm) ∧ A.trustLevel(untrusted) ∧ ¬(A.hasPermission(WAKE LOCK)) ∧ B.trustLevel(trusted) ∧ B.name(com.android.deskclock)

goal ProtectMusic(deny) := L.hasSource(A) ∧ L.hasDestination(B) ∧ L.type(ICC.direct) ∧ A.trustLevel(untrusted) ∧ ¬(A.hasPermission(WAKE LOCK)) ∧ B.trustLevel(trusted) ∧ B.name(com.android.music) ∧ B.component(com.android.music.MediaPlaybackService)

goal ProtectSettingsWiFi(deny) := L.hasSource(A) ∧ L.hasDestination(B) ∧ L.type(ICC.direct) ∧ L.hasCategory(Intent.CATEGORY ALTERNATIVE) ∧ L.hasData(0:0#0) ∧A.trustLevel(untrusted) ∧ A.hasPermission(CHANGE WIFI STATE) ∧ B.trustLevel(trusted) ∧ B.name(com.android.settings) ∧ B.component(com.android.settings.widget.SettingsAppWidgetprovider)

goal ProtectSettingsLocation(deny) := L.hasSource(A) ∧ L.hasDestination(B) ∧ L.type(ICC.direct) ∧ L.hasCategory(Intent.CATEGORY ALTERNATIVE) ∧ L.hasData(3:3#3)∧ A.trustLevel(untrusted) ∧ ¬(A.hasPermission(ACCESS FINE LOCATION)) ∧ B.trustLevel(trusted) ∧ B.name(com.android.settings) ∧ B.component(com.android.

settings.widget.SettingsAppWidgetprovider)

goal ProtectSettingsBluetooth(deny) := L.hasSource(A) ∧ L.hasDestination(B) ∧ L.type(ICC.direct) ∧ L.hasCategory(Intent.CATEGORY ALTERNATIVE) ∧ L.hasData(4:4#4) ∧ A.trustLevel(untrusted) ∧ ¬(A.hasPermission(BLUETOOTH ADMIN)) ∧ B.trustLevel(trusted) ∧ B.name(com.android.settings) ∧ B.component(com.android.settings.widget.SettingsAppWidgetprovider)

goal ProtectASE(deny) := L.connects(A,B) ∧ L.type(Internet) ∧ A.trustLevel(untrusted) ∧ ¬(A.hasPermission(SEND SMS)) ∧ B.trustLevel(untrusted) ∧ B.name(ASE)

goal PreventLocationLeackage(deny) := L.connects(A,B) ∧ L.type(ICC.direct) ∧ A.trustLevel(untrusted) ∧ A.hasPermission(ACCESS FINE LOCATION) ∧ B.trustLevel(untrusted) ∧ B.hasPermission(INTERNET)

goal PreventContactsLeackage(deny) := L.connects(A,B) ∧ L.type(ICC.direct) ∧ A.trustLevel(untrusted) ∧ A.hasPermission(READ CONTACTS) ∧ B.trustLevel(untrusted) ∧B.hasPermission(INTERNET)

goal PreventSMSLeackage(deny) := L.connects(A,B) ∧ L.type(ICC.direct) ∧ A.trustLevel(untrusted) ∧ A.hasPermission(READ SMS) ∧ B.trustLevel(untrusted) ∧ B.hasPermission(INTERNET)

goal ProtectCallPrivacy(deny) := L.connects(A,B) ∧ L.type(any) ∧ A.trustLevel(untrusted) ∧ ¬(A.hasPermission(INTERNET) ∧ (A.hasPermission(PHONE STATE) ∨ A.hasPermission(PROCESS OUTGOING CALL)) ∧ B.trustLevel(untrusted) ∧ ¬(B.hasPermission(PHONE STATE) ∨ B.hasPermission(PROCESS OUTGOING CALL)) ∧ B.hasPermission(INTERNET)

goal AllowApplicationLaunch(allow) := L.hasSource(A) ∧ L.hasDestination(B) ∧ L.type(ICC.direct) ∧ L.hasActionString(android.intent.action.MAIN) ∧ L.hasCategory(android.intent.category.LAUNCHER) ∧ A.trustLevel(untrusted) ∧ (B.trustLevel(trusted) ∨ B.trustLevel(untrusted))

Figure 8. Policy rules used for testing expressed in a policy language

Figure 9. Visualization of the ICC based communication during user tests. Selected System Servicesand Content Providers are illustrated as separate nodes

Figure 10. Visualization of file system and socket access by third party apps. Grey nodes representbenign applications, red nodes represent colluding applications, black nodes represent files andblue nodes represent sockets. On the bottom left are two examples of colluding applications: onepair of apps (WriteSD and ReadSD) collude by means of a shared file on the SDcard, while anotherpair (LocalSocket Client and LocalUnixSocket Server) collude using a socket in a client-server model