On Demystifying the Android Application Framework: Re ... · PDF fileOn Demystifying the...

This paper is included in the Proceedings of the 25th USENIX Security Symposium

August 10–12, 2016 • Austin, TX

ISBN 978-1-931971-32-4

Open access to the Proceedings of the 25th USENIX Security Symposium

is sponsored by USENIX

On Demystifying the Android Application Framework: Re-Visiting Android Permission

Specification AnalysisMichael Backes, Saarland University and Max Planck Institute for Software Systems

(MPI-SWS); Sven Bugiel and Erik Derr, Saarland University; Patrick McDaniel, The Pennsylvania State University; Damien Octeau, The Pennsylvania State University

and University of Wisconsin—Madison; Sebastian Weisgerber, Saarland University

https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/backes_android

USENIX Association 25th USENIX Security Symposium 1101

On Demystifying the Android Application Framework:Re-Visiting Android Permission Specification Analysis

Michael BackesCISPA, Saarland University & MPI-SWS

Saarland Informatics Campus

Sven BugielCISPA, Saarland University


Erik DerrCISPA, Saarland University


Patrick McDanielPennsylvania State University

Damien OcteauPennsylvania State University &

University of Wisconsin

Sebastian WeisgerberCISPA, Saarland University


AbstractIn contrast to the Android application layer, An-droid’s application framework’s internals and theirinfluence on the platform security and user privacyare still largely a black box for us. In this paper, weestablish a static runtime model of the applicationframework in order to study its internals and providethe first high-level classification of the framework’sprotected resources. We thereby uncover design pat-terns that differ highly from the runtime model atthe application layer. We demonstrate the bene-fits of our insights for security-focused analysis ofthe framework by re-visiting the important use-caseof mapping Android permissions to framework/SDKAPI methods. We, in particular, present a novel map-ping based on our findings that significantly improveson prior results in this area that were establishedbased on insufficient knowledge about the frame-work’s internals. Moreover, we introduce the conceptof permission locality to show that although frame-work services follow the principle of separation ofduty, the accompanying permission checks to guardsensitive operations violate it.

1 Introduction

Android’s application framework—i.e., the middle-ware code that implements the bulk of the AndroidSDK on top of which Android apps are developed—is responsible for the enforcement of Android’spermission-based privilege model and as such is alsoa popular subject of recent research on security exten-sions to the Android OS. These extensions providevarious security enhancements to Android’s security,ranging from improving protection of the user’s pri-vacy [26, 46], to establishing domain isolation [29, 12],to enabling extensible access control [21, 8].

Android’s permission model and its security exten-

sions are currently designed and implemented as best-effort approaches. As such they have raised questionsabout the efficacy, consistency, or completeness [3] ofthe policy enforcement. Past research has shown thateven the best-efforts of experienced researchers anddevelopers working in this environment introducepotentially exploitable errors [15, 44, 35, 33]. In lightof the framework size (i.e., millions of lines of code)and based on past experience [15, 44, 16, 33, 36],static analysis promises to be a suitable and effectiveapproach to (help to) answer those questions andhence to demystify the application framework from asecurity perspective. Unfortunately, on Android, thetechnical peculiarities of the framework impingingon the analysis of the same have not been inves-tigated enough. As a consequence, past attemptson analyzing the framework had to resort to simplestatic analysis techniques [7]—which we will show inthis paper as being insufficient for precise results—orresort to heuristics [33].

In order to improve on this situation and to raiseefficiency of static analysis of the Android applicationframework, one is confronted with open questionson how to enable more precise static analysis of theframework’s codebase: where to start the analysis(i.e., what is the publicly exposed functionality)?Where to end the analysis (i.e., what are the dataand control flow sinks)? Are there particular designpatterns of the framework runtime model that impedeor prevent a static analysis? For the Android applica-tion layer, those questions have been addressed in alarge body of literature. Thanks to those works, thecommunity has a solid understanding of the sinks andsources of security- and privacy-critical flows withinapps (e.g., well-known Android SDK methods) and adedicated line of work further addressed various chal-lenges that the Android application runtime modelposes for precise analysis (e.g., inter-component com-munication [28, 40, 24, 27] or modelling the Android

1102 25th USENIX Security Symposium USENIX Association

app life-cycle[25, 6]). Together those results form astrong foundation on which effective security- andprivacy-oriented analysis is built upon. In contrastto the app layer, for the application framework wehave an intuitive understanding of what constitutesits entry points, but no in-depth technical knowledgehas been established on the runtime model, and al-most no insights exist on what forms the securityand privacy relevant targets of those flows (i.e., whattechnically forms the sinks or “protected resources”).

Our Contributions. This paper contributes tothe demystification of the application framework froma security perspective by addressing technical ques-tions of the underlying problem on how to staticallyanalyze the framework’s code base. Similar to the de-velopment of application layer analyses, we envisionthat our results contribute some of the first results toa growing knowledge base that helps future analysesto gain a deeper understanding of the applicationframework and its security challenges.

How to statically analyze the application framework.We present a systematic top-down approach, start-ing at the framework’s entry points, that establishesknowledge and solutions about analyzing the controland data flows within the framework and that makesa first technical classification of the security and pri-vacy relevant targets (or resources) of those flows.The task of establishing a precise static runtimemodel of the framework was impeded by the absenceof any prior knowledge about framework internalsbeyond black-box observations at the framework’sdocumented API and manual analysis of code frag-ments. Hence we generate this model from scratchby leveraging existing results on statically analyzingAndroid’s application layer at the framework layer.The major conceptual problem was that the designpatterns of the framework strongly differ from thepatterns that had been previously encountered andstudied at the application layer. Consequently wedevised a static analysis approach that systematicallyencompasses all framework peculiarities while main-taining a reasonable runtime. As result of this overallprocess, we have established a dedicated knowledgebase that subsequent analyses involving the applica-tion framework can be soundly based upon.

Axplorer tool and evaluation. Unifying the lessonslearned above, we have built an Android applicationframework analysis tool, called Axplorer. We eval-uate Axplorer on four different Android versions—v4.1.1 (API level 16), v4.2.2 (17), v4.4.4 (19), andv5.1 (22)—validate our new insights and demonstratehow specialized framework analyses, such as message-

based IPC analysis and framework component inter-connection analysis, can be used to speed up sub-sequent analysis runs (e.g. security analyses) by75% without having to sacrifice precision. As addi-tional benefit the resulting output can be used byindependent work as is to create a precise static run-time model of the framework without the need tore-implement the complex IPC analysis.

Android permission analysis. Finally, to demonstratethe benefits of our insights for security analysis ofthe framework, we conduct an Android permissionanalysis. In particular, we re-visit the challenge ofcreating a permission map for the framework/SDKAPI. In the past, this problem has been tackled [32, 7]without our new insights in the peculiarities of theframework runtime model, and our re-evaluation ofthe framework permission map reveals discrepanciesthat call the validity of prior results into question.Using Axplorer, we create a new permission mapthat improves upon related work in terms of precision.Moreover, we introduce a new aspect of permissionanalysis, permission locality, by investigating whichframework components enforce a particular permis-sion. We found permissions that are checked in up to10 distinct and not necessarily closely related com-ponents. This indicates a violation of the separationof duty principle and can impede a comprehensiveunderstanding of the permission enforcement.

2 Background

We first provide necessary technical background in-formation on the Android software stack and theabstract control and data flows in the system. An-droid OS is an open source software stack on topof the Linux OS. Between the apps at the top ofthe stack and the Linux kernel at the bottom is theAndroid middleware. This middleware consists ofthe application runtime environment, default nativelibraries (like SSL), and the Java-based applicationframework (see Figure 1).

2.1 Android Application FrameworkThe application framework consists of the variousservices that implement the Android app API (e.g.,retrieving location data or telephony functionality).Every framework service is responsible for provid-ing access to one specific system resource, such asgeolocation, radio interface, etc.

Bound services. These services are implementedas bound services [4] as part of the SystemServer.

2


WiFi Manager Location Manager

WiFi Service(Bound Service)

Location Service(Bound Service)

SDK

App Framework

Linux OS + Hardware

App AppSystem Apps

(Contacts, SMS, Dialer,...)

Inter-Process Communication

...

Native Lib Native Lib

...

Native Libraries

Figure 1: Android Software Stack with abstract controland data flows.

Bound service is the fundamental pattern to realizeAndroid services that are remotely callable via a well-defined interface. Such interfaces are described in theAndroid Interface Definition Language (AIDL) andan AIDL compiler allows automated generation ofStub and Proxy classes that implement the interface-specific Binder-based RPC protocol to call the service.Here, Stubs are an abstract class that implementsthe Binder interface and needs to be extended bythe actual service implementation. Proxies are usedby clients to call the service. On top of Stubs andProxies, the Android SDK provides Managers as ab-straction from the low-level RPC protocol. Managerclasses encapsulate pre-compiled Proxies and allowdevelopers to work with Manager objects that trans-late local method calls into remote-procedure calls totheir associated service and hence enable app devel-opers to easily engage into RPC with the framework’sservices. However, Proxies and Managers are justabstractions for the sake of app developer’s conve-nience and nothing prevents an app developer frombypassing the Managers or re-implementing the de-fault RPC protocol to directly communicate with theservices.

A small number of framework services does notuse AIDL to auto-generate their Stub/Proxy, butinstead provides a custom class that implements theBinder interface. The most prominent exceptionis the ActivityManagerService (AMS), which pro-vides essential services such as application life-cyclemanagement or Intent distribution. Since its in-terface is also called from native code, for whichthe AIDL compiler does not auto-generate nativeProxies/Stubs and hence requires manual imple-mentation of those, the RPC protocol for the AMS ishardcoded to avoid misalignment between manuallywritten and auto-generated code.

The services are an essential part of the middle-ware front-end to the application layer and callingtheir interfaces triggers control and data flows withinthe application framework. Naturally, the flows ofsome services lead to interaction with the underlyingplatform through the native libs. For instance, theWifiService is interacting with the WiFi daemon.Other services, such as Clipboard, do not rely onany hardware features. However, the exact controland data flows have not yet been studied or charted(see blank boxes in Figure 1) and facilitating thismapping by enabling analysis of the framework ispart of the contributions of this work.

System apps. System apps, such as Contacts, Di-aler, or SMS complement the application frameworkwith commonly requested functionality. However, incontrast to the application framework services thatare fixed parts of any Android deployment, systemapps are exchangeable or omittable (as can be ob-served in the various vendor customized firmwares)and, more importantly, are simply apps that are pro-grammed against the same application frameworkAPI as third-party applications.

2.2 PermissionsOne cornerstone of the Android security design arepermissions, which an app must hold to successfullyaccess the security and privacy critical methods ofthe application framework. Every application onAndroid executes under a distinct Linux UID andpermissions are simply Strings1 that are associatedwith the application’s UID. There is no centralizedpolicy for checking permissions on calls to theframework API. Instead, framework services thatprovide security or privacy critical methods toapplications (must) enforce the corresponding,hard-coded permission that is associated with thesystem resources that the services expose. Toenforce permissions, the services programmaticallyquery the system whether their currently callingapp—identified by its UID—holds the requiredpermission, and if not take appropriate actions(such as throwing an exception). For instance, theLocationManagerService would query the systemwhether a calling UID is associated with the Stringandroid.permission.ACCESS_FINE_LOCATION,which represents the permission to retrieve the GPSlocation data from the LocationManagerService.

In this model, system apps differ from third-partyapps in that they can successfully request security

1Permissions that map to Linux GIDs do not involve theframework and are not further considered here.

3


and privacy critical system permissions from theframework, which are not available to non-systemapps. Moreover, like framework services (and anynon-system application), they are responsible for en-forcing permissions for resources they manage andexpose on their RPC interfaces (e.g., contacts infor-mation or initiating phone calls). The difference tonon-system applications is, that they usually enforcewell-known permissions defined in the Android SDK,although the Android design does—in contrast tothe framework services—not hardcode where thosepermissions are enforced, thus allowing system appsto be exchanged.

3 Related work

Static (app) analysis. Different related workshave analyzed Android apps for vulnerabilities andprivacy violations. Enabling precise static app analy-sis required solving essential questions like what arethe entry points of the app, what are the securityrelevant sinks and how can we achieve a static run-time model that takes the application peculiaritiesinto account? Among the static analysis approaches,CHEX [25] was the first tool to accommodate forAndroid’s event-driven app lifecycle with an arbi-trary number of entry points. FlowDroid [6] furtherimproved the runtime model by automatically gen-erating per-component lifecycle models that takeinto account the partial entry point ordering. WhileFlowDroid still analyzed components in isolation, anumber of related works specifically addressed theproblem of inter-component communication (ICC).The initial work Epicc [28] devised a new analysistechnique to create specifications for each ICC sinkand source. Amandroid [40] combined a lifecycle-aware program dependence graph with ICC analysisto generate an inter-component model of the ap-plication to improve precision for various securityapplications. Similarly, IccTA [24] extended Flow-Droid with a precise inter-component model. Finally,IC3 [27] uses composite constant propagation to im-prove retargeting of ICC-related parameters enablinga more precise ICC resolution. Moving from besteffort approaches, SuSi [5] took a machine-learningapproach for classifying and categorizing sources andsinks in the framework code that are relevant for ap-plication analysis. All of those solutions contribute toanalyzing Android apps more efficiently. The focusof this work is on establishing similar knowledge onAndroid’s application framework and on making afirst essential but non-trivial step towards enabling aholistic analysis of Android that includes the frame-work code with its security architecture.

Application Framework Abstractions. Theapplication framework is generally regarded as toocomplex to be considered in an app analysis (cf.,CHEX [25]) and very recent works dealt specifi-cally with this problem of abstracting the applicationframework [13, 18] or making it amenable for appanalysis [11]. EdgeMiner [13] links callback meth-ods to their registration methods and generates APIsummaries that describe implicit control flow transi-tions through the framework. DroidSafe [18] distillsa compact, data-dependency-aware model of the An-droid app API and runtime from the original frame-work code. Droidel [11] differs in its approach byexplicating the reflective bridge between the appli-cation framework and applications, while trying tomodel the framework as less as possible. It generatesapp-specific versions of the application frameworkand replaces reflective calls with app-specific stubs.All of these approaches try to pre-compute data-dependencies through the framework API that canbe used by app analyses in favor of using the com-plex and huge framework code base. In contrast, ourwork makes a first step towards enabling in-depthanalyses of the application framework beyond justdata dependencies in order to enable future reasoningabout framework security architectures or extensions(such as guiding and verifying hook placement orseparation of duties).

Permission Mapping and Inconsistencies.Both Stowaway [32] and PScout [7] built permis-sion maps for the framework API. Stowaway usedunit testing and feedback directed API fuzzing of theframework API to observe the required permission(s)for each API call. PScout, in contrast, used staticreachability analysis between permission checks andAPI calls to create a permission mapping of differentAndroid framework versions that improves on the re-sults of Stowaway. Permission maps have since been avaluable input to different Android security research,such as permission analysis [20] and compartmen-talization [31, 34] of third-party code, studying appdeveloper behavior [32, 38], detecting component hi-jacking [25], IRM [23, 10] and app virtualization [9],or risk assessment [30, 19, 45, 42]. In this work, were-visit the challenge of creating a permission map forAndroid. In contrast to the prior work, we build ontop of our new insights on how to statically analyzethe application framework (see Sections 4 and 5),which allow us to achieve a map that is more precisefor the application framework API and that calls thevalidity of some prior results [7] into question. Wediscuss how recent work [33] that focused on incon-sistent security enforcement within the framework

4


could benefit from a deeper understanding of theframework’s peculiarities separately in Section 8.

Android Security Frameworks. Various secu-rity extensions have been proposed, such as [26, 46,29, 12, 21, 8] to name a few, which integrate autho-rization hooks into Android’s application frameworkto enforce a broad range of security policies. At themoment, those extensions are designed and imple-mented as best-effort approaches that raise questionsabout the completeness and consistency of the en-forcement and indeed past research has shown thateven the best-efforts of highly experienced researchersand developers working in this environment intro-duce potentially exploitable errors [15, 44, 35, 33].This unsatisfying situation has strong parallels toearlier work on integrating authorization hooks intothe Linux and BSD kernels [41, 39], where a dedi-cated line of work [15, 44, 16] has established toolsand techniques to reason about the security proper-ties of proposed extensions or to automate the hookplacement. Prerequisite for those solutions was aclear understanding of what constitutes a resourcethat is (or should be) protected by an authorizationhook. To allow development of similar tools for theAndroid application framework, we hence have toalso answer the question about Android’s protectedresources first. In this work we want to make a firstessential step in this direction by enabling a deeperanalysis of the framework and by providing a firsthigh-level taxonomy of protected resources in theapplication framework.

4 Enabling In-Depth ApplicationFramework Analysis

In contrast to the various related works on staticanalysis at the application level, there is no exist-ing prior work on in-depth analysis of the applica-tion framework. Moreover, as the architecture ofthe framework fundamentally differs from the archi-tecture of applications, open questions have to beanswered first to be able to conduct in-depth staticanalysis of the framework. For instance, “what arethe entry points to the application framework?” or“how to establish a static runtime model of the frame-work’s control flows?” In the following we identifychallenges that arise for static analyses at frameworklevel and present a systematic, top-down approach tocope with these problems (an implementation of ourapproach is presented in Section 5). Solving the dis-cussed challenges lays the foundation on which a widerange of security analyses of the application frame-

work can be constructed, from which we (re-)visitthe use-case of permission analysis in Section 7.

4.1 Defining Framework Entry PointsThe first question to be answered is how to iden-tify and select the starting points for the frameworkanalysis? At application level this has already beenstudied in depth [25, 6, 14, 17, 43]. From a high-levelview, most approaches parse the declared compo-nents from the application manifest and determinethe components as well as dynamically registeredcallbacks as entry points; or they build componen-t/application life-cycle models with a single mainentry method.

Challenge: The framework model is conceptuallydifferent from the application layer and existingapproaches for application layer analysis do notapply in a framework analysis. Instead one hasto identify the framework API methods that areexposed to app developers as analysis entry points.

To identify the entry point methods, we have tolocate the relevant framework entry point classes.Starting with the official API of the Android SDK(e.g., Managers in Figure 1) is not reliable as there areno means to prevent an app developer from bypassingthe SDK by immediately communicating with theframework services or by using reflection to accesshidden API methods of the SDK. Consequently, wedo not consider the API calls within the SDK asentry points but instead the framework classes thatare entry points for accessing framework functionality(i.e., framework classes that are being called by theSDK, see Figure 1). We exclude entry points thatare not accessible by app developers, such as Zygote,service manager, or the property service, which areunder special protection (e.g., SELinux [37]) and willnot accept commands by third-party apps that havetangible side-effects on the system or other apps. Thisrestriction is in accordance with the design of existingAndroid security extensions, which exclusively focuson the exported functionality of the app framework(e.g., framework’s bound services).

Inter-component communication in Android is bydesign based on Binder IPC and, thus, frameworkclasses have to expose functionality via Binder inter-faces to the application layer. To this end, interfacesmust be derived from IInterface, the base classfor Binder interfaces. Binder interfaces might beautomatically generated by AIDL, in this case theentry point classes extend the auto-generated Stubclass, or in case of Binder interfaces that are not gen-erated by AIDL, a custom Binder implementation

5


like ActivityManagerNative2 has to be provided,which in turn is extended by the entry point classes.These class relationships can be resolved via a classhierarchy analysis (CHA) to determine the set ofall entry classes. Besides bound services this alsoincludes callback and event listener classes that ex-pose an implementable interface to app developers.Hence, we define entry points (EP) as the publicmethods of framework classes that are exposed via aBinder interface. In addition, permission-protectedentry points (PPEP) are defined as entry points fromwhich a permission check is control-flow reachable.

4.2 Building a Static Runtime Model

Challenge: Generating a static model that ap-proximates the runtime behaviour of the applicationframework again strongly differs from the problemsthat arise at application level where the componentlife-cycles are mimicked to approximate runtime be-havior. The bound services—as entry points to theframework—might be queried simultaneously frommultiple clients (apps) via IPC and hence have tohandle multi-threading to ensure responsiveness ofthe framework. In contrast to the application spaceat which utility classes like AsyncTask are used forthreading, we discovered that the framework ser-vices make intensive use of more generic but alsomore complex threading mechanisms like Handler,AsyncChannel, and StateMachines. Disregardingthese concurrency patterns results in imprecise datamodels that cause a high number of false positivesduring framework analysis.

In the following, we provide technical background forthose asynchronicity patterns and explain how theycan modeled correctly for static analyses.

Handler. The class android.os.Handler pro-vides a mechanism for reacting to messages or sub-mitting Java Runnable objects for execution on a(potentially remote) thread. Handlers either sched-ule the processing of a message or the execution ofa Runnable at some point in the future or process amessage/Runnable on a separate thread.

To illustrate the Handler mechanism, considerthe example shown in Listing 1. It includesthe relevant sections of the framework classcom.android.server.BluetoothManagerService.When the service is constructed, it instantiatesa HandlerThread object (line 6), a traditionalThread object associated with a Looper. The

2By convention non-generated class names end with Native.

1 class BluetoothManagerService {2 private HandlerThread mThread ;3 private BluetoothHandler mHandler ;45 public BluetoothManagerService () {6 mThread = new

HandlerThread (" BluetoothManager ");7 mThread . start ();8 mHandler = new

BluetoothHandler ( mThread . getLooper ());9 }

10 public void enable () {11 Message msg =

mHandler . obtainMessage ( MESSAGE_ENABLE );12 mHandler . sendMessage (msg);13 }14 public void disable () {15 Message msg =

mHandler . obtainMessage ( MESSAGE_DISABLE );16 mHandler . sendMessage (msg);17 }1819 class BluetoothHandler extends Handler {20 public void handleMessage ( Message msg) {21 switch (msg.what) {22 case MESSAGE_ENABLE :23 // process enable message24 break ;25 case MESSAGE_DISABLE :26 // process disable message27 break ;28 // Other cases .29 }}}30 }

Listing 1: Bluetooth Handler in the Bluetoothmanager service. Code was simplified for readabililty.

purpose of the Looper class is to sequentially processthe messages in a message queue. At line 8, theclass-specific BluetoothHandler object is createdand associated with the newly created Looperfrom the HandlerThread. This allows messagessent to the BluetoothHandler to be pushed to themessage queue for this Looper. Methods enableand disable can be called by applications viaRPC on IBluetoothManager to turn the bluetoothfunctionality on or off. Method enable sendsa message with code MESSAGE_ENABLE to theBluetoothHandler (line 12). When the associatedLooper instance processes the message, it callsmethod handleMessage in the BluetoothHandler(line 20), which then processes the request.

Statically resolving message-based IPC, requiresto overcome several challenges. First, the targetHandler type has to be inferred, to determine the con-crete handleMessage method of the receiving classthat processes the message. Second, to add precisionto the analysis, it is best to make it locally path-sensitive by inferring the possible message codes ofthe arguments to sendMessage methods. For the ex-ample presented in Listing 1, this enables the analysisto be limited to the feasible paths for a given messagein the switch at line 21. While it is possible to per-

6


form the analysis without this information, doing soresults in a significant loss of precision and, thus, anincrease in the number of false positives, which maydistort the results of security analyses built on top.In light of the prevalence of the Handler pattern,this loss of precision is not an acceptable solution.Finally, since messages can also be associated withrunnable tasks instead of message codes, the con-crete Runnable types associated with each messagehave to be inferred to determine the runnable codeexecuted when such a message is processed.

AsyncChannel. Closely related to Handlers,com.android.internal.util.AsyncChannel im-plements a bi-directional channel between twoHandler objects. It provides its own sendMessageand replyToMessage methods, both of which dele-gate to the sendMessage methods in its associatedHandler. In order to precisely model AsyncChannelobjects, it is necessary to infer the types of thesender/receiver Handler objects. Similarly toHandlers, path-sensitivity should be added to theanalysis by inferring the message codes that are sentthrough the channel.

StateMachine. Building on the Handler concept,the com.android.internal.util.StateMachineclass models complex subsystems such as the DHCPclient or the WiFi connectivity manager. Thisclass allows processing of messages dependingon the current state of the modeled system. Iteffectively constitutes a hierarchical state machinein which messages cause state transitions. Statesare organized in a hierarchical manner, such thatparent states may process messages that are nothandled by child states. In order to precisely modelstate machines, several challenges must be addressed.First, the subtype of the state machine itself must beinferred, with all the states and possible transitions.Second, the hierarchy of the states must be inferred,in order to know which enter and exit statemethods are called upon state transitions. Moreover,this is necessary to know which state may handle agiven message. Third, for eliminating further falsepositives one needs to infer the possible states forany given program location at which interactionwith the state machine occurs.

4.3 Identifying Protected ResourcesWhile the previous sections show how static analy-sis of the android application framework code basecan be enabled, we now classify the resources in-side the application framework that actually have

to be protected. Unfortunately, there is a lack ofconsensus in the community on what constitutesa security-sensitive resource/operation [5, 16] andno one-size-fits-all definition exists as the concretedefinition depends on various aspects like operatingsystem, programming language, or even the domain.To avoid ambiguities on what we denote as protectedresource in the remainder of this paper, we note thatprotected resources for us are security sensitive oper-ations that have a tangible side effect on the systemstate or use of privacy.

Challenge: Defining the security-relevant re-sources is, in contrast to entry points, more chal-lenging. For privacy leak analysis at application-level, there is a well-defined list of API methodsthat can be classified as sinks. Since the analysisnow shifts into the API methods of the framework,it is unclear what kind of resources are protectedby Android’s permissions and can, thus, be used assinks for security analysis within the framework.

To create a first high-level taxonomy of protectedresources that can help to automatically discoversuch resources, we first have to create a ground truthabout what technically forms a protected resource.To this end, we manually investigated control flowsof a number of identified PPEP in the framework’ssource code. Here, we make the assumption thatevery existing permission check within the applica-tion framework indeed controls access to at least onesecurity- or privacy-critical system resource. Checksare usually located at the very beginning of PPEP, sothat any subsequent operation is indeed authorized.Using expert knowledge in combination with descrip-tions of expected side effects from the Android docu-mentation we identify and annotate relevant state-ments that modify the service and/or system state.To avoid a potential bias in the types of protectedresources, we chose entry points from eight differententry classes. To cover a variety of disjunct cases, webased our selection on the available information suchas return value, number/type of EP input arguments,or number/type of permission checks collected duringthe entry point discovery. After manually investigat-ing flows from 35 entry points, distinct repetitivepatterns for protected resources appeared across thedifferent control flows, which we summarized in ataxonomy of the high-level protected resource types.

Taxonomy of protected resources. Figure 2presents our high-level taxonomy of the protected re-source types. In contrast to work at application-levelthat disregards field instructions [5], we found thatfield update instructions are highly relevant in the

7


context of the framework and in fact are the mostprevalent type of protected resources that we discov-ered. Relevant method invocations can be further sub-classified into native method calls (e.g. for file systemaccess or modification of device audio settings) andbroadcast sender. We consider native method callsgenerally as protected resources, since distinguishingnon-/security-relevant native calls would require adedicated analysis for the native code, which is cur-rently a general, open problem for the communityand out of scope for this work. Broadcast senders areprotected resources as they can potentially cause inthe receivers side-effects on the system or apps. How-ever, this is statically unresolvable, as the concreteside-effects strongly depend on the current systemconfiguration, e.g. on the installed apps and the setof active broadcast listener. We consider non-voidreturn values of security-sensitive entry methods asprotected resource. Returned objects of such meth-ods constitute sensitive data, e.g., a list of WiFiconnections. Return values of primitive types int orboolean may constitute sensitive values like for themethod isMultiCastEnabled of the WifiServiceor some status/error code in method enableNetworkof the same service. We also found cases in whicha throw RuntimeException (RTE) has to be consid-ered as a protected resource. For instance, in thecrash method of the PowerManagerService, whichrequires from the caller the permission to reboot thedevice, an RTE causes the runtime to crash and thedevice to reboot in consequence.

Coverage of the taxonomy. An inherent limita-tion of our taxonomy based on small-scaling manualanalysis is, that there are no guarantees that cornercases are included in the current classification. Tocover all corner cases in our taxonomy, a compre-hensive manual analysis of the framework would berequired, which would defeat the purpose of enablinga static analysis in the first place. This constitutesa high-level taxonomy of protected resource (types)in the framework. Distilling a more refined set forsecurity analyses is discussed separately in Section 8.

5 Implementation

We combined all aforementioned steps from Section 4for analysis of an arbitrary framework version intoa tool called Axplorer. We leverage the staticanalysis framework WALA [2], although our approachis equally applicable to other analysis frameworkssuch as Soot [1]. Additional code for realizing ourapproach comprises ≈15 kLOC of Java.

Protected Resource

Field updates

Method invocations

Return values

Throw instructions Throw Run-timeException

Native methodinvocations

Broadcast sender

Figure 2: High-level taxonomy of protected resourceoperation types.

Call-graph generation. For each identified en-try class, we generate an inter-procedural call-graph(CG). As opposed to related approaches [7] that useclass hierarchy analysis to generate low-precision call-graphs due to the overall framework complexity—Android version 4.2.2 already includes over 35,000classes—we generate high-precision call-graphs withobject-sensitive pointer resolution. For each virtualor interface invocation we infer the runtime type(s)and hence precisely connect the invocation to itstarget(s). Although the costs for the points-to com-putation are computational very expensive, the in-creased precision lowers the complexity of the overallcall-graph, since we do not introduce imprecision byconsidering all subclasses of a virtual method call aspotential receivers. Avoiding this imprecision in thecall-graph also lowers the number of false positives.The complexity is further reduced by the design de-cision to not follow RPC calls to other entry classes.We complement the call-graph with message-basedIPC edges during the control-flow slicing (see below).

Slicing & on-demand msg-based IPC resolu-tion. We conduct a forward control-flow slice foreach identified entry point method. The slicer stopsat native methods, RPC invocations to classes otherthan the current one, and when the entry pointmethod returns. During slicing, we perform an on-demand message/handler resolution to add message-based IPC edges to the call-graph, thus avoiding ahuge computational overhead of computing all edgesin advance when only a subset of them are requiredfor analysis (e.g. if PPEP are analyzed only).

When the slicer reaches a sendMessage call, we in-fer the concrete handler type and add a call edge fromthe sendMessage call to the handleMessage methodof the receiving handler. We augment this processwith inter-procedural backwards slicing for two rea-sons: First, since existing type inference algorithms(like the ones implemented in WALA) work intra-procedurally, type inference fails if Handler objectsare stored in fields whose declared field type is the

8


Handler base class and not the concrete subtype. Us-ing inter-procedural backwards slicing starting at themessage-sending instruction, we obtain a more pre-cise set of possible handler types in Axplorer. Sec-ond, Messages are usually not constructed explicitlybut indirectly obtained via calls to Message.obtainor Handler.obtainMessage and contain a public in-teger field that carries a sender-defined message codethat allows the recipient to identify the message type.To statically identify the message code we computea backwards slice starting from the message-sendinginstruction and check the resulting set of instructionsfor calls that construct/obtain a message. We thenrepeat this approach starting from the message ob-tain call to infer the concrete message code used toinitialize the Message.

Handlers use switch statements to match the pro-vided message code and to transfer control-flow toa specific basic block of the method’s control-flowgraph (cf. line 25 et seqq. in Listing 1). To avoidinfeasible paths, we have to recreate path-sensitivityintra-procedurally and map the message code(s) tothe individual execution path(s). The control-flowslicer then continues at this specific execution path toavoiding a huge number of false positives. Runnabletypes on a post call of the Handler are resolvedin the same way and a call edge to the Runnable’srun method is added. The approach slightly differsin case of StateMachines. Here, there is no singlehandleMessage function. Instead, each State im-plements its own processMessage function. In thiscase, we recreate path-sensitivity for each of thesefunctions and delegate the control-flow to any match-ing switch statement.

6 Framework Complexity Analysis

We apply our gained insights from Section 4 to col-lect complexity information about the applicationframework. By doing this, we demonstrate how theanalysis complexity can be held manageable to allowsuch in-depth analysis within a reasonable amount oftime. Finally, we collect the framework’s protectedresources as denoted in our taxonomy and validatethe results (a detailed discussion on how securityanalyses can benefit from this is given in Section 8).Using Axplorer we analyze four different Androidversions: 4.1.1 (API level 16), 4.2.2 (17), 4.4.4 (19),and the latest Lollipop release 5.1 (22).

6.1 Handling Framework ComplexityTable 1 summarizes different complexity statisticsgenerated for the four analyzed versions. Unsur-

prisingly, the complexity in terms of code increaseswith each version, whereas the gap to the most re-cent major version is significantly larger as betweenthe minor version changes due to new features likeAndroid TV. The entry class discovery algorithmidentified between 242–383 entry classes of which≈25% include at least one PPEP. The evaluation wasconducted on a server with four Intel Xeon E5-4650L2.60 GHz processors with 8 cores each and 768 GBRAM. Initial processing of the frameworks finishedin reasonable time, ranging from 14–126 hours. Notethat this computation has to be done only once perAndroid version and that there are no real-time con-straints as, e.g., in application vetting. The mosttime-consuming task (about 85% of the overall time)was generation of the high-precision call-graphs. Inthe following, we describe the use of entry-class inter-connection and IPC analysis to speed up processingtime without loosing the precision of our data model.

Entry class interconnection. IPC-interfaces offramework entry classes are not only used by theapplication layer, but also by other framework ser-vices. Analyzing the communication behavior ofentry classes does not only provide a deeper under-standing of how the framework services are inter-connected but also facilitates analyses that rely onpermission checks as security indicator (e.g., see Sec-tion 7). Exploiting the knowledge about which ser-vice EP triggers which RPCs along its control flowenables pre-computation of execution path conditionsand restricting the scope of a service analysis to onlysubsets of dependent services rather than the entireframework (i.e, it allows to efficiently divide and con-quer the framework analysis). In a post-processingstep the analysis results for distinct services can bestitched together at RPC boundaries. Appendix Aillustrates the RPC interconnections for Android 5.1.

Message-based IPC Analysis. A precise modelof the message sender to handler relations is crucialfor the generation of a static runtime model of theframework with a low number of false connections.The last row in Table 1 shows the prevalence of themessage sending pattern. Between 38–52% of PPEPinclude at least one message sending call. Across APIlevels we found 300 (API 16) to over 500 (API 22)distinct message sender calls used within PPEP. Theevaluation of our IPC analysis showed that in 7% ofall cases the message was sent to a StateMachine,and in 27% of all cases to a Handler. In the remain-ing 66% a Runnable was posted. This ratio remainsapproximately the same in all versions. Overall, ourIPC analysis was able to fully resolve about 76%

9


Android version 4.1.1 (16) 4.2.2 (17) 4.4.4 (19) 5.1 (22)

# of classes 27,749 29,804 31,023 46,192- inner classes 14,784 15,936 17,525 28,933

# of entry point classes 242 256 284 383- with at least one PPEP 64 (26.4%) 73 (28.5%) 75 (26.4%) 81 (21.2%)

# entry methods (EP) 2,583 2,734 2,861 3,225- with perm check (PPEP) 863 (33.4%) 1,018 (37.2%) 1,227 (42.9%) 1,250 (38.8%)

- incl. message sending 328 (38.0%) 532 (52.2%) 518 (42.2%) 597 (47.8%)

Table 1: Comparing complexity measures for different Android versions (percentages relate to preceding line).

of all message sending instances, yielding alreadya very valuable data set of the message sender tohandler relationships. Reasons for failed resolutionare that either the Handler (81%) or Runnable (5%)could not correctly be inferred while in the remaining13% of cases the message code could not be inferred.The root cause of most of these failures is the miss-ing/incomplete support of AsyncChannels and theMessage.sendToTarget() API call. At the time ofwriting this support is work-in-progress.

During our initial analysis run Axplorer recordsboth an RPC-map per entry class as well as a list ofresolved sender-to-handler relationships. This datais then re-applied as expert knowledge in subsequentanalysis re-runs to significantly reduce the analysisruntime, e.g., for API level 17, the processing timedrops by ~75% to about 7 hours. By publishingthis data we hope that independent analyses canequally benefit from this by removing the burden tore-implement a comparable IPC resolution algorithm.

Reflection We analyzed reflection usage withinframework code by counting the number of callsto methods within the java.lang.reflect package.The absolute numbers range from 89 (API 16) to118 (API 22). Across API levels less than 50% tar-geted the Method class while the remaining calls weredistributed among other reflection classes. In manycases reflection is used in utility or debug classesand we found only one entry class that makes use ofreflection (ConnectivityService), but the respec-tive method was removed in API level 20. In SDKcode the total numbers are slightly higher acrossAPI levels (115–288). However, the additional usageof reflection is mainly due to View/Widget classes.Overall, reflection is only rarely used in frameworkcode and not used at all by main service components.

6.2 Android’s Protected ResourcesTo validate our established taxonomy, we collect theprotected resources for each Android version andclassify them with respect to the taxonomy. Across

versions the total number ranges from 6,5k (API 16)to 10k (API 22). Although these numbers seem quitehigh at first glance, they are reasonable in relationto the overall size and complexity of the framework.Axplorer recorded the context depth (in terms ofmethod invocations) at which the protected resourceswere found. While for simple methods that includefew (or only even one) resource the call depth islower than two, the median call depth ranges from8–11 across Android versions. This emphasizes thatapproaches that do not perform in-depth analysis arenot suitable to detect resources located deeper in thecontrol-flow. The relative distribution of resourcesper type is stable across all versions. We validatedour statement of Section 4.3 that field update instruc-tions are the most prevalent resource type (with ashare of about 75%). They are followed by nativemethod calls (about 21–23%), which are most fre-quently used as a gateway to the device hardware (e.g.file system, audio, nfc). There is a surprisingly lownumber of PPEP that return a protected value, theabsolute number ranges from 51–69 entries. Anotherunexpected result is that runtime exceptions occurwith a frequency that is about as high as protectedbroadcast senders. Besides the already mentioned ex-ample within the PowerManagerService, we foundoccurrences in UI widget classes and even in thedefault XML parsing library on Android.

Appendix B gives more detailed statistics on pro-tected resources, as well as a manual validation andassessment of the use of RTE in the framework.

7 Permission Analysis

Building on top of our new insights we re-visit an im-portant aspect of Android’s permission specification,that is permission mapping between permission checkand SDK method, and further introduce permissionlocality to study which framework components per-form which permission checks. To this end we extendAxplorer as follows:

1) A PPEP only indicates the presence of apermission check in the control-flow from this

10


entry-point, but there is no information yet aboutthe number of checks or the concrete permissionstrings. We extend our slicing-based approach to alsoresolve the permission strings in common permissioncheck API invocations (e.g., as defined in theContext class). Non-constant strings are resolved ina similar way like message codes in Section 5. From520 distinct permission checks found in API level 16,we were able to resolve 99% of the permission strings.Among the failing cases, one case was located in theActivityManagerService$PermissionControllerclass where the permission string is an argument ofthe entry point method, which is only called fromnative code and hence was not statically resolved.

2) Entry class interconnection, i.e., RPC tran-sitions to other PPEP (see Section 6.1), usuallyaccumulates all permissions required by the ad-ditionally called entry classes for the UID thatcalled the first entry class in the control-flow.However, those transitions are irrelevant for per-mission analysis when the RPC is located be-tween calls to Binder.clearCallingIdentity andBinder.restoreCallingIdentity. Clearing thecalling UID in the framework’s bound services re-sets it from the calling app’s UID to the privilegedsystem server UID. Thus, outgoing IPC edges afterclearing and before restoring the UID should be ig-nored in permission analysis, since the additionalPPEP are called with a UID that is different fromthe calling app’s UID.

3) We add a light-weight SDK analysis to reasonabout required permissions of documented APIs. Tothis end, we conduct a reachability analysis from pub-lic SDK methods to framework EPs (SDK to frame-work layer in Figure 1). Combining this mappingwith the mapping from framework EPs to permis-sions creates a permission map for the documentedAPI.

7.1 Re-Visiting Permission MappingThe Stowaway project [32] were the first to generatea comprehensive permission map for Android 2.2.Their dynamic analysis approach (feedback directedAPI fuzzing) generates precise but incomplete results.Moreover, the involved manual effort makes it diffi-cult to re-use it for newer API versions. PScout [7]improved on this situation by statically analyzingthe framework code, thus increasing the code cover-age. In direct comparison PScout’s results containnotably more permission mappings. To handle thecomplexity induced by the framework size, PScoutresorts to low-precision data models based on classhierarchy information. In the following, we demon-

strate that this has negative implications for theirresulting permission map. Using our insights we pro-vide permission mappings that call the validity ofprior mappings into question.

We compare our results with PScout using theirlatest available results (for Android 4.1.1) 3. Since weexclude Intent and ContentProvider permissions,which both require supplemental analysis effort suchas manifest or URI object parsing, we restrict thecomparison to un-/documented APIs. For the eval-uation we include the standard system apps andmake identical assumptions as PScout, i.e., we as-sume that any permission found for a particular APIis indeed required (a more precise analysis wouldrequire path-sensitivity). Moreover, like PScout, wedid not conduct a native code analysis.

7.1.1 Documented API map

Figure 3 shows for our documented API map (SDKEP to permissions) how often a certain permissionis required. For some permissions PScout reportshigher numbers while for others Axplorer reportshigher numbers. Since the results are fairly devi-ating, we manually inspected various cases, includ-ing a full analysis of NFC and bluetooth, to ver-ify correctness of our generated numbers. PScout’shigher method count, particularly for the two cases ofNFC and bluetooth, originates from adding package-protected methods that are not exposed to app de-velopers and from improper handling of the @hidejavadoc4 attribute, resulting in an overcounting of thedocumented API methods. Our higher numbers ofBROADCAST_STICKY and SET_WALLPAPER mainly re-fer to abstract methods from the Context class thatare implemented in its subclass ContextWrapper andthen inherited by 18 non-abstract subclasses (for API16). Instead, PScout only lists those methods for theContext/-Wrapper class, thus missing to count thenon-abstract subclasses.

Figure 4 provides a different view of the map-ping by showing the distribution of required permis-sions per API. The main difference is the smallernumber of outliers in our data set: four mappingswith three or more required permissions, comparedto 58 such outliers in the PScout data set. Whilethe different results in Figure 3 mainly originatefrom technical shortcomings in the SDK analysis,Figure 4 hints at the different quality of the un-documented API map as result of a more precise

3We use PScout’s results as published on their website athttp://pscout.csl.toronto.edu. Last visited 01/25/2016.

4EP methods annotated with the @hide attribute are notincluded in the SDK.

11


11

11

11

111

23

23

22

216

22

33

324

38

44

58

618

66

77

88

89

911

1222

1217

1313

1820

2121

3045

4562

489

5810

6183

ACCESS_LOCATION_EXTRA_COMMANDS

SET_TIME_ZONE

SET_WALLPAPER_HINTS

USE_CREDENTIALS

CHANGE_WIFI_MULTICAST_STATE

GET_TASKS

KILL_BACKGROUND_PROCESSES

MANAGE_ACCOUNTS

REORDER_TASKS

DISABLE_KEYGUARD

GET_ACCOUNTS

VIBRATE

CHANGE_NETWORK_STATE

ACCESS_NETWORK_STATE

MODIFY_AUDIO_SETTINGS

SEND_SMS

AUTHENTICATE_ACCOUNTS

ACCESS_MOCK_LOCATION

READ_PHONE_STATE

ACCESS_WIFI_STATE

BLUETOOTH_ADMIN

CHANGE_WIFI_STATE

USE_SIP

ACCESS_COARSE_LOCATION

ACCESS_FINE_LOCATION

WAKE_LOCK

BLUETOOTH

BROADCAST_STICKY

SET_WALLPAPER

NFC

0 25 50 75Number of documented API mappings

AxplorerPScout

Figure 3: Number of documented APIs per permission.

framework analysis (see next Section 7.1.2). PScout’smore light-weight framework analysis results in anover-approximation of permission usage of EPs. Fortheir outliers with more than five permissions inthe ConnectivityManager class they either over-approxmiate the receivers of a sendMessage calland/or did not resolve the message code and thecorrect path in the handleMessage method. In suchcases the over-approximation in the framework analy-sis negatively influences the quality of the SDK mapwhen IPC calls from the SDK to the applicationframework are connected. We manually validated alloutliers and found that no method actually requiresmore than three permissions, thus contradicting thePScout results. The four outliers in our datasetcheck at most two permissions, independent of theEP call arguments. Additional permission checksmight be required for specific arguments/parameters.For instance the setNetworkPreference(int) func-tion of the ConnectivityService will tear down aspecific type of network trackers depending on a pref-erence integer argument. Some subtypes such asthe BluetoothTetheringDataTracker require bothbluetooth permissions to execute this functionalitywhile other subtypes require no additional permis-

314365

34 464

330 4 0 19 0 1 0 1

0

100

200

300

400

1 2 3 4 5 6 7Number of required permissions

Doc

umen

ted

API c

ount Axplorer (Total: 352)

PScout (Total: 469)

Figure 4: Number of permissions required by a docu-mented API.

sion. Adding parameter-sensitivity to the analysis isrequired to resolve such cases automatically and toannotate permission checks with conditions.

7.1.2 Undocumented API map

A fair, direct comparison of permission maps forundocumented APIs is unfortunately very difficultdue to shortcomings in the original paper. AlthoughPScout did not explicitly define the term undocu-mented API, we assume after manual inspection oftheir results that it refers to the publicly exposedframework interfaces and covers any functionalitythat can be called from application level (indepen-dent of whether it is provided by SDK or systemapps). Hence we refer to undocumented API as theentire set of framework entry points (cf. Section 4.1).

In contrast to PScout’s documented API map, wediscovered different inconsistencies in their undoc-umented mappings. Besides valid mappings fromPPEP to permissions, they also include mappings forunrelated methods. First, public methods of AIDL-based entry classes (which we define as Entry Points)are counted up to five times: once in the SDK man-ager class, in the framework service class, in the AIDLinterface class, and in the auto-generated Stub andProxy classes. Second, their mapping contains meth-ods of StateMachine State classes. StateMachinesare used framework-internally and their functionalityis not exposed to apps. Third, synthetic accessormethods as well as methods of anonymous innerclasses are reported. We assume that this problem isrelated to the lack of a concise entry point definitionthat induces difficulties with the abort criteria duringtheir backwards analysis starting from permissionchecks. In contrast, our forward analysis seems moresuitable in this context, as permission checks areusually closely located to framework EPs.

Table 1 reports on the numbers of entry points perAPI level. For Android 4.1.1, Axplorer found 863PPEP (33.4% of entry points) that require at leastone permission. These numbers include signature/-

12


OrSystem permissions since this information, al-though not interesting for app developers, is of inter-est for understanding the Android permission modelin its entirety. On average we found 1.17 permissionsper PPEP, which leads to a total of 1,012 permissionmappings that cover 129 distinct permissions. Thisis a magnitude less than the 32,304 permission map-pings reported by PScout for normal and dangerouspermissions only. However, due to our more concisedefinition of what constitutes public framework func-tionality and the inclusion of all permission levels,we argue that our number is more substantiated.

7.2 Permission LocalityThe application framework implements a separationof duty: every bound service is responsible for man-aging a certain system resource and enforcing per-missions on access by apps to them. For instance,the LocationService manages and protects locationrelated information or the PhoneInterfaceManagerfacilitates and guards access to the radio interfaces.Permission strings already convey a meaning of thekind of system resource they protect and app develop-ers might have an intuition where those permissionsare required. We study whether permission checkingalso follows the principle of separation of duty andpermissions are checked by only one particular service.We call this aspect permission locality. A low per-mission locality indicates that a certain permissionis enforced at different (possibly unrelated) services.This potentially contributes to the app developer’spermission incomprehension that can lead to over-privileged apps [32]. Moreover, a strict separation ofduty, i.e., high permission locality, significantly easesthe task of implementing (and verifying) authoriza-tion hooks for resources, for instance in the designof recent security APIs [21, 8]. Consequently, thepermission that protects a set of sensitive operationsis ideally checked only in one associated entry class.

To study the permission locality, we analyze thechecked permission strings and map them to theenclosing class of the permission check call. In An-droid v4.1.1 (API level 16) we found that out of110 analyzed permissions 22 (20%) are checked inmore than one class. Among these permissions, 13are checked in two classes, 5 in three classes and4 in four classes. An example for seemingly un-related classes are LocationManagerService andPhoneInterfaceManager that both check the dan-gerous permission ACCESS_FINE_LOCATION. Whilethe permission is intuitively related to the first ser-vice, the connection to the latter one becomes onlyobvious by looking at the enclosing method that

includes the check (e.g. getCellLocation). Inter-estingly, PhoneInterfaceManager is not a frame-work service but included in the telephony systemapp. Mixing framework services and system apps forenforcing identical permissions complicates permis-sion validation and policy enforcement, since systemapps might be vendor-specific. Grouping permis-sions by protection level results in 22.2% (12/54) ofnormal/dangerous permissions and 17.9% (10/56) ofsignature/-OrSystem permissions being checked indistinct classes. This implies that low permissionlocality equally affects all protection levels. Ap-plying this analysis on API 22 results in a evenlower overall permission locality. Focusing on thefour outliers in API 16, changes in API 22 includethree class renamings, two removals and nine ad-ditions (cf. Figure 6 in Appendix C). The permis-sion CONNECTIVITY_INTERNAL more than doubledthe number of classes (10) in which it is enforced.This evolution of permission checks indicates a dis-concerting trend to lower permission locality.

Instead, the permission locality should be increasedby, ideally, associating each permission with a singleservice. Once a designated owner service has beenidentified for each permission, a dedicated permis-sion check function could be publicly exposed viaits Binder interface, e.g., a method to check theACESSS_FINE_LOCATION permission could be addedto the ILocationManager interface. The additionand removal of callers to such methods then no longeraffects the number of decision points and preservesthe separation of duty for permission checks.

8 Discussion of Other Use-Cases

We briefly discuss further use-cases that can benefitfrom our work, particularly from our taxonomy ofprotected resources and the insights from our per-mission locality analysis.

Permission check inconsistencies. Prior workKratos has shown that the default permission checkis inconsistent and can lead to attacks [33]. However,this approach explicitly did not make the attempt toidentify protected resources in Android’s applicationframework but instead relied on arbitrary shared codeas heuristic to identify security relevant hotspots inthe framework’s code base. While this approach hassuccessfully demonstrated the need for such analy-sis, we argue that using our definition of protectedresources as refinement of shared code can furtherimprove the precision of their analysis, since, by defi-nition, protected resources describe sensitive opera-tions. False positives originating from shared logging

13


or library code are automatically eliminated then.Distilling a more concise definition of field-updateand native method call resources from our high-leveltaxonomy is a promising future work. An examplefor such refinement is the removal of non-relevantfield updates of a this reference within constructors.As there is no prior state for this object, such updatesmust not be flagged as protected resource.

Authorization hook placement. Different An-droid framework extensions [26, 46, 29, 12, 21, 8]augment the application framework with authoriza-tion hooks in a best effort approach. On commoditysystems, a comparable situation for the Linux andBSD kernels has been improved through a long pro-cess that established a deeper understanding of theinternal control and data flows of those kernels andthat allowed development of tools to verify or auto-mate placement of authorization hooks. A similarevolution for Android’s application framework hasyet been precluded due to open technical challenges:first, one must be able to analyze control and dataflows in the framework across process and serviceboundaries; second one must be able to track theexecution state of the framework service along itsinternal control and data flows (e.g., tracking theavailability of the subject identity); third, one has toestablish a clear and very specific understanding ofthe protected resources of each service. This workat hand addresses the first of these challenges andprovides necessary permission locality informationto implement comprehensive, coarse-grained enforce-ment models. Additionally, with our high-level tax-onomy of protected resources we made a first steptowards solving the third challenge.

9 Conclusion

In this paper, we studied the internals of the An-droid application framework, in particular challengesand solutions for static analysis of the framework,and provided a first high-level classification of itsprotected resources. We applied our gained insightsto improve on prior results of Android permissionmappings, which are a valuable input to differentAndroid security research branches, and to introducepermission locality as a new aspect of the permis-sion specification. Our results showed that Androidpermission checks violate the principle of separationof duty, which might motivate a more consolidateddesign for permission checking in the future. To allowapp developers and independent research to bene-fit from our results, we published our data sets as

well as lint rules for our permission mappings for theAndroid Studio IDE at http://www.axplorer.org .

Acknowledgments

This work was supported by the German Fed-eral Ministry for Education and Research (BMBF)under project VFIT (16KIS0345) and SmartPriv(16KIS0377K) through funding for the Center for IT-Security, Privacy and Accountability (CISPA) andthe initiative for excellence of the German federalgovernment.

References[1] Soot - Java Analysis Framework. http://sable.github.

io/soot/, 1999.[2] T.J. Watson Libraries for Analysis (WALA). http://

wala.sf.net, 2006.[3] Anderson, J. P. Computer security technology planning

study, volume ii. Tech. Rep. ESD-TR-73-51, Deputy forCommand and Management Systems, HQ ElectronicsSystems Division (AFSC), L. G. Hanscom Field, Oct.1972.

[4] Android Developer Documentation. Bound services.http://developer.android.com/guide/components/bound-services.html. Last visited: 05/08/2015.

[5] Arzt, S., Bodden, E., and Rasthofer, S. A machine-learning approach for classifying and categorizing An-droid sources and sinks. In Proc. 21th Annual Networkand Distributed System Security Symposium (NDSS ’14)(2014), The Internet Society.

[6] Arzt, S., Rasthofer, S., Fritz, C., Bodden, E., Bar-tel, A., Klein, J., le Traon, Y., Octeau, D., andMcDaniel, P. Flowdroid: Precise context, flow, field,object-sensitive and lifecycle-aware taint analysis for An-droid apps. In Proc. ACM SIGPLAN 2014 Conferenceon Programming Language Design and Implementation(PLDI 2014) (2014).

[7] Au, K. W. Y., Zhou, Y. F., Huang, Z., and Lie, D.Pscout: Analyzing the android permission specification.In Proc. 19th ACM Conference on Computer and Com-munication Security (CCS ’12) (2012), ACM.

[8] Backes, M., Bugiel, S., Gerling, S., and von Styp-Rekowsky, P. Android Security Framework: Extensiblemulti-layered access control on Android. In Proc. 30thAnnual Computer Security Applications Conference (AC-SAC ’14) (2014), ACM.

[9] Backes, M., Bugiel, S., Hammer, C., Schranz, O.,and von Styp-Rekowsky, P. Boxify: Full-fledged AppSandboxing for Stock Android. In Proc. 24th USENIXSecurity Symposium (SEC ’15) (2015), USENIX.

[10] Backes, M., Gerling, S., Hammer, C., Maffei, M.,and von Styp-Rekowsky, P. Appguard - enforcing userrequirements on Android apps. In Proc. 19th Interna-tional Conference on Tools and Algorithms for the Con-struction and Analysis of Systems (TACAS ’13) (2013).

[11] Blackshear, S., Gendreau, A., and Chang, B.-Y. E.Droidel: A general approach to android framework mod-eling. In Proc. ACM SIGPLAN Workshop on State ofthe Art in Program Analysis (SOAP’15) (2015), ACM.

14


[12] Bugiel, S., Heuser, S., and Sadeghi, A.-R. Flexibleand fine-grained mandatory access control on Androidfor diverse security and privacy policies. In Proc. 22ndUSENIX Security Symposium (SEC ’13) (2013), USENIXAssociation.

[13] Cao, Y., Fratantonio, Y., Bianchi, A., Egele, M.,Kruegel, C., Vigna, G., and Chen, Y. EdgeMiner: Au-tomatically Detecting Implicit Control Flow Transitionsthrough the Android Framework. In Proc. 22nd AnnualNetwork and Distributed System Security Symposium(NDSS ’15) (2015), ISOC.

[14] Chaudhuri, A., Fuchs, A., and Foster, J. SCanDroid:Automated security certification of Android applications.Tech. Rep. CS-TR-4991, University of Maryland, 2009.

[15] Edwards, A., Jaeger, T., and Zhang, X. Runtime ver-ification of authorization hook placement for the Linuxsecurity modules framework. In Proc. 9th ACM Confer-ence on Computer and Communication Security (CCS’02) (2002), ACM.

[16] Ganapathy, V., Jaeger, T., and Jha, S. Automaticplacement of authorization hooks in the Linux SecurityModules framework. In Proc. 12th ACM Conferenceon Computer and Communication Security (CCS ’05)(2005), ACM.

[17] Gibler, C., Crussell, J., Erickson, J., and Chen, H.Androidleaks: automatically detecting potential privacyleaks in android applications on a large scale. In Proc.5th international conference on Trust and TrustworthyComputing (TRUST ’12) (2012), Springer-Verlag.

[18] Gordon, M. I., Kim, D., Perkins, J. H., Gilham, L.,Nguyen, N., and Rinard, M. C. Information flow anal-ysis of android applications in DroidSafe. In Proc. 22ndAnnual Network and Distributed System Security Sym-posium (NDSS ’15) (2015), ISOC.

[19] Gorla, A., Tavecchia, I., Gross, F., and Zeller, A.Checking app behavior against app descriptions. In Proc.36th International Conference on Software Engineering(ICSE ’14) (2014), pp. 1025–1035.

[20] Grace, M., Zhou, W., Jiang, X., and Sadeghi, A.-R.Unsafe exposure analysis of mobile in-app advertisements.In Proc. 5th ACM conference on Security and Privacyin Wireless and Mobile Networks (WISEC ’12) (2012),ACM.

[21] Heuser, S., Nadkarni, A., Enck, W., and Sadeghi, A.-R. Asm: A programmable interface for extending androidsecurity. In Proc. 23rd USENIX Security Symposium(SEC ’14) (2014), USENIX.

[22] Huang, H., Zhu, S., Chen, K., and Liu, P. From systemservices freezing to system server shutdown in android:All you need is a loop in an app. In Proc. 22nd ACMConference on Computer and Communication Security(CCS’15) (2015), ACM.

[23] Jeon, J., Micinski, K. K., Vaughan, J. A., Fogel,A., Reddy, N., Foster, J. S., and Millstein, T. Dr.Android and Mr. Hide: Fine-grained security policies onunmodified Android. In Proc. 2nd ACM workshop onSecurity and privacy in smartphones and mobile devices(SPSM ’12) (2012), ACM.

[24] Li, L., Bartel, A., Bissyandé, T. F., Klein, J.,Le Traon, Y., Arzt, S., Rasthofer, S., Bodden, E.,Octeau, D., and Mcdaniel, P. IccTA: Detecting Inter-Component Privacy Leaks in Android Apps. In Proc.37th International Conference on Software Engineering(ICSE ’15) (2015).

[25] Lu, L., Li, Z., Wu, Z., Lee, W., and Jiang, G. CHEX:Statically Vetting Android Apps for Component HijackingVulnerabilities. In Proc. 19th ACM Conference on Com-puter and Communication Security (CCS ’12) (2012),ACM.

[26] Nauman, M., Khan, S., and Zhang, X. Apex: Ex-tending Android permission model and enforcement withuser-defined runtime constraints. In Proc. 5th ACM Sym-posium on Information, Computer and CommunicationSecurity (ASIACCS ’10) (2010), ACM.

[27] Octeau, D., Luchaup, D., Dering, M., Jha, S., andMcDaniel, P. Composite Constant Propagation: Ap-plication to Android Inter-Component CommunicationAnalysis. In Proc. 37th International Conference onSoftware Engineering (ICSE ’15) (2015).

[28] Octeau, D., McDaniel, P., Jha, S., Bartel, A., Bod-den, E., Klein, J., and Le Traon, Y. Effective inter-component communication mapping in Android withEpicc: An essential step towards holistic security anal-ysis. In Proc. 22Nd USENIX Conference on Security(SEC ’13) (2013), USENIX Association.

[29] Ongtang, M., McLaughlin, S. E., Enck, W., and Mc-Daniel, P. Semantically rich application-centric securityin Android. In Proc. 25th Annual Computer SecurityApplications Conference (ACSAC ’09) (2009), ACM.

[30] Pandita, R., Xiao, X., Yang, W., Enck, W., and Xie,T. Whyper: Towards automating risk assessment ofmobile applications. In Proc. 22nd USENIX SecuritySymposium (SEC ’13) (2013), USENIX.

[31] Pearce, P., Porter Felt, A., Nunez, G., and Wagner,D. AdDroid: Privilege separation for applications andadvertisers in Android. In Proc. 7th ACM Symposium onInformation, Computer and Communications Security(ASIACCS ’12) (2012), ACM.

[32] Porter Felt, A., Chin, E., Hanna, S., Song, D., andWagner, D. Android permissions demystified. In Proc.18th ACM Conference on Computer and CommunicationSecurity (CCS ’11) (2011), ACM.

[33] Shao, Y., Ott, J., Chen, Q. A., Qian, Z., and Mao,Z. M. Kratos: Discovering inconsistent security policyenforcement in the android framework. In Proc. 23rdAnnual Network and Distributed System Security Sym-posium (NDSS ’16) (2016), ISOC.

[34] Shekhar, S., Dietz, M., and Wallach, D. S. Ad-split: Separating smartphone advertising from applica-tions. In Proc. 21st USENIX Security Symposium (SEC’12) (2012), USENIX Association.

[35] Song, D., Zhao, J., Burke, M. G., Sbirlea, D.,Wallach, D., and Sarkar, V. Finding tizen secu-rity bugs through whole-system static analysis. CoRRabs/1504.05967 (2015).

[36] Tan, L., Zhang, X., Ma, X., Xiong, W., and Zhou, Y.Autoises: Automatically inferring security specificationsand detecting violations. In Proc. 17th USENIX SecuritySymposium (SEC ’08) (2008), USENIX.

[37] The Android Open-Source Project. Security-Enhanced Linux in Android. http://source.android.com/devices/tech/security/selinux/index.html. Lastvisited: 07/27/2015.

[38] Vidas, T., Christin, N., and Cranor, L. F. Curbingandroid permission creep. In Proc. Workshop on Web2.0 Security and Privacy 2011 (W2SP 2011) (2011).

15


[39] Watson, R., Morrison, W., Vance, C., and Feld-man, B. The TrustedBSD MAC Framework: Exten-sible kernel access control for FreeBSD 5.0. In Proc.FREENIX Track: 2003 USENIX Annual Technical Con-ference (2003), USENIX Association.

[40] Wei, F., Roy, S., Ou, X., and Robby. Amandroid: APrecise and General Inter-component Data Flow AnalysisFramework for Security Vetting of Android Apps. In Proc.21th ACM Conference on Computer and CommunicationSecurity (CCS ’14) (2014), ACM.

[41] Wright, C., Cowan, C., Smalley, S., Morris, J., andKroah-Hartman, G. Linux Security Modules: Generalsecurity support for the Linux kernel. In Proc. 11thUSENIX Security Symposium (SEC ’02) (2002), USENIXAssociation.

[42] Wu, L., Grace, M., Zhou, Y., Wu, C., and Jiang,X. The impact of vendor customizations on androidsecurity. In Proc. 20th ACM Conference on Computerand Communication Security (CCS ’13) (2013), ACM.

[43] Yang, Z., and Yang, M. Leakminer: Detect informationleakage on Android with static taint analysis. In Proc.2012 Third World Congress on Software Engineering(WCSE ’12) (2012), IEEE Computer Society.

[44] Zhang, X., Edwards, A., and Jaeger, T. Usingcqual for static analysis of authorization hook placement.In Proc. 11th USENIX Security Symposium (SEC’ 02)(2002), USENIX.

[45] Zhang, Y., Yang, M., Xu, B., Yang, Z., Gu, G., Ning,P., Wang, X. S., and Zang, B. Vetting undesirablebehaviors in android apps with permission use analy-sis. In Proc. 20th ACM Conference on Computer andCommunication Security (CCS ’13) (2013), ACM.

[46] Zhou, Y., Zhang, X., Jiang, X., and Freeh, V. Tam-ing information-stealing smartphone applications (onAndroid). In Proc. 4th International Conference onTrust and Trustworthy Computing (TRUST ’11) (2011),Springer-Verlag.

16


Appendix

A Entry Class Interconnection

A standard call graph gives information about theenclosing method/class of function calls. However,this information is insufficient to provide informationabout the interconnection of framework entryclasses. Instead, the interesting information isthe originating entry class that leads to an RPCrather than the actual class that encloses theRPC. To provide better information on the RPCdependencies of entry classes, Axplorer creates anRPC map by recording RPCs to other entry classesand mapping them to the original entries duringcontrol-flow slicing. Figure 5 shows a subgraph ofthe overall RPC interconnections between flowsfrom different entry classes on Android 5.1 thatAxplorer generated. Nodes correspond to entryclasses and are weighted by in-/out-degree, thushighlighting highly-dependent classes such asActivityManagerService. The source of a directededge is the originating entry class: the control-flowstarts at an entry method of this class and at somepoint along the flow, not necessarily in the sameclass, an RPC to the class of the edge target node isinvoked.

Across all four investigated Android versionsthere is a median number of three distinct RPCreceivers per entry class in our map. TheActivityManagerService is an exceptional casewhere flows from its entry methods reach 36 dif-ferent entry classes. These numbers emphasize thatlarge parts of the framework are strongly connectedand that detailed knowledge about the communica-tion behavior greatly simplifies further frameworkanalyses as explained above.

B Evaluation of protected resources

B.1 Statistics on protected resourcesTable 2 provides absolute numbers of protected re-sources by API version and the distribution by re-source types.

B.2 Manual investigation of RTEDue to the surprisingly high number of runtimeexceptions and the fact that uncaught RTEmight potentially crash the system, we manuallyinvestigated the corresponding code locations tobetter understand their security implications. The

AccountManagerService

UserManagerService

PackageManagerServiceContentServiceSipService

WifiServiceImpl

UsbService

UiAutomationConnectionContactsProvider2

CountryDetectorServiceProfileProvider

ClipboardService

Trampoline

PendingIntentRecord

WifiScanningServiceImpl

BatteryStatsServiceWifiNetworkScoreCache

PackageInstallerService PackageInstallerSession

NetworkPolicyManagerService

ConnectivityService

NetworkStatsService

NetworkScoreServiceAppOpsService

NetworkManagementService

MountService

LocationManagerService

EthernetServiceImpl

ActivityManagerService

CommandQueue

WindowManagerService

DropBoxManagerService

MonkeyNetworkMonitor

ProcessStatsService

StatusBarManagerService

BluetoothManagerService

AccessibilityManagerService

LockSettingsService

AudioService

Nat464Xlat

Tethering

DevicePolicyManagerService

AppWidgetServiceImpl

SessionBaseIWindow

What this graph showsOriginating Entry Point (EP)

abstraction(in graph)

control-flow(not in graph)

RPC Target EP

Enclosingclass

Figure 5: Subgraph of overall entry class interconnec-tion via RPCs in Android 5.1. Directed edges show anRPC to an exposed IInterface method of target node.

source code analysis revealed that these instructionsreside both in Android’s code base and in externallibrary code. Android, similar to other operatingsystems, relies on external libraries for specifictasks, such as XMLPullParser, Bouncy Castle, andJ-SIP. Integrating library code into such a complexsystem usually raises the question on how to handleunchecked exceptions that are thrown by libraryfunctions. Either the library code is patched, whichmight be a tedious maintenance task, or exceptionsare caught at caller site. Although the latter case isconsidered bad practice in case of runtime exceptions,using generic catch handler around library call sitesis the easiest and most reliable approach in thissituation.

Runtime exceptions in the Android code arethrown to indicate precondition violations, like cru-cial class fields being null, unrecoverable IO errors, orsecurity violations. The implications of a runtime ex-ception differ with respect to code location in whichthey are thrown. Exceptions in the application layer,i.e. in system applications, cause the respective appto crash. Similarly as for normal apps, they can berestarted by the user. Sticky system app services arerestarted automatically by the system. Exceptionsthrown in bound services of the SystemServer arehandled in a special way: A system watchdog threadcom.android.server.Watchdog constantly moni-tors the core services like PowerManagerService andActivityManagerService. In case of a crash ordeadlock, it reboots the entire system. Uncaughtruntime exceptions in unmonitored system servicescause the Android Runtime, including Zygote and

17


Android version 4.1.1 (16) 4.2.2 (17) 4.4.4 (19) 5.1 (22)

# of protected resources 6,490 6,969 7,488 10,044- field updates 4,891 (75.36%) 5,268 (75.59%) 5,675 (75.79%) 7,520 (74.87%)- native method calls 1,433 (22.08%) 1,499 (21.51%) 1,643 (21.94%) 2,305 (22.95%)- return value 51 ( 0.79%) 60 (0.86%) 54 (0.72%) 69 (0.69%)- broadcast sender 65 ( 1.00%) 72 (1.03%) 53 (0.71%) 78 (0.78%)- throw runtime exception 50 ( 0.77%) 70 (1.01%) 63 (0.84%) 72 (0.71%)

Median context depth 8 9 11 9

Table 2: Numbers on protected resources by type and Android version.

the SystemServer to be restarted (hot reboot) whilethe kernel keeps running—effects also described inrecent research [22].

C Statistics on permission locality

Table 3 shows a detailed statistic about the number ofpermissions in API 16 that are checked in more thanone class, grouped by their protection level. Thesenumbers imply that there is no apparent correlationabout the relative frequency and the protection level,in particular between the permissions available tothird-party apps (normal+dangerous) and the onesreserved for the system. Hence, low permission lo-cality cases occur across all permission protectionlevels.

Protection level # permissions

normal 2/16 (12.5%)dangerous 10/38 (26.3%)signature 2/25 (8%)signatureOrSystem 8/31 (25.8%)

Table 3: Number of permissions in API 16 that arechecked in more than one class grouped by permissionprotection level.

Figure 6 lists all four permissions that are checkedin four distinct entry classes in API level 16(colors denote changes in API 22). In case ofREAD_PHONE_STATE, those four classes even residein four distinct packages of which one is part ofthe telephony system app. Although it may not al-ways be easy to identify one dedicated service as thepermission owner, an effort might be desirable tocentralize permission checks into as few services aspossible (in best case into a single service). Besidesrenamed classes (blue color) as result of a code refac-toring process, the number of additions and removalfor this small number of examples clearly confirmsthat permission checks are violating the separation ofduty and underline the need for central enforcementpoints.

Permission : ACCESS_NETWORK_STATELevel : normalChecked in :

- com.android.server.ConnectivityService- com.android.server.ethernet.EthernetServiceImpl- com.android.server.ThrottleService- com.android.server.net.NetworkPolicyManagerService- com.android.server.net.NetworkStatsService

Permission : READ_PHONE_STATELevel : dangerousChecked in :

- com.android.internal.telephony.PhoneSubInfoProxy- com.android.phone.PhoneInterfaceManager- com.android.internal.telephony.SubscriptionController- com.android.server.TelephonyRegistry- com.android.server.net.NetworkPolicyManagerService

Permission : CONNECTIVITY_INTERNALLevel : signatureOrSystemChecked in :

- com.android.server.ConnectivityService- com.android.server.NetworkManagementService- com.android.server.NsdService- com.android.server.net.NetworkPolicyManagerService- com.android.server.net.NetworkStatsService- com.android.server.ethernet.EthernetServiceImpl- com.android.server.connectivity.Tethering- com.android.bluetooth.pan.PanService$BluetoothPanBinder- com.android.server.wifi.WifiServiceImpl- com.android.server.wifi.p2p.WifiP2pServiceImpl

Permission : UPDATE_DEVICE_STATSLevel : signatureOrSystemChecked in :

- com.android.server.power.PowerManagerService$BinderService- com.android.server.LocationManagerService- com.android.server.am.BatteryStatsService- com.android.server.wifi.WifiServiceImpl- com.android.server.am.UsageStatsService

Figure 6: Permissions checked in four distinct classesin API 16. Colors denote changes in API 22: renamedclasses (blue), additions (green) and removals (red).

18

On Demystifying the Android Application Framework: Re ... · PDF fileOn Demystifying the...

Documents

Transcript of On Demystifying the Android Application Framework: Re ... · PDF fileOn Demystifying the...