ieee transactions on software …lilicoding.github.io/sa3repo/papers/2015_bagheri2015covert.pdfit...

0098-5589 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. Seehttp://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citationinformation: DOI 10.1109/TSE.2015.2419611, IEEE Transactions on Software Engineering

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING 1

COVERT: Compositional Analysis of AndroidInter-App Permission Leakage

Hamid Bagheri, Alireza Sadeghi, Joshua Garcia and Sam Malek, Member, IEEE

Abstract—Android is the most popular platform for mobile devices. It facilitates sharing of data and services among applicationsusing a rich inter-app communication system. While access to resources can be controlled by the Android permission system,enforcing permissions is not sufficient to prevent security violations, as permissions may be mismanaged, intentionally orunintentionally. Android’s enforcement of the permissions is at the level of individual apps, allowing multiple malicious appsto collude and combine their permissions or to trick vulnerable apps to perform actions on their behalf that are beyond theirindividual privileges. In this paper, we present COVERT, a tool for compositional analysis of Android inter-app vulnerabilities.COVERT’s analysis is modular to enable incremental analysis of applications as they are installed, updated, and removed.It statically analyzes the reverse engineered source code of each individual app, and extracts relevant security specificationsin a format suitable for formal verification. Given a collection of specifications extracted in this way, a formal analysis engine(e.g., model checker) is then used to verify whether it is safe for a combination of applications—holding certain permissionsand potentially interacting with each other—to be installed together. Our experience with using COVERT to examine over 500real-world apps corroborates its ability to find inter-app vulnerabilities in bundles of some of the most popular apps on the market.

Index Terms—Formal Verification, Static Analysis, Android, Inter-App Vulnerabilities

F

1 INTRODUCTION

Mobile app markets are creating a fundamentalparadigm shift in the way software is delivered tothe end users. The benefits of this software supplymodel are plenty, including the ability to rapidly andeffectively acquire, introduce, maintain, and enhancesoftware used by the consumers. By providing amedium for reaching a large consumer market at anominal cost, app markets have leveled the softwaredevelopment industry, allowing small entrepreneursto compete with prominent software developmentcompanies. Application frameworks are the key en-ablers of these markets. An application framework,such as the one provided by Android, ensures appsdeveloped by a wide variety of suppliers can inter-operate and coexist together in a single system (e.g.,a phone) as long as they conform to the rules andconstraints imposed by the framework.

This paradigm shift, however, has given rise toa new set of security challenges. In parallel withthe emergence of app markets, we are witnessingan increase in the security threats targeted at mobileplatforms. This is nowhere more evident than in theAndroid market (i.e., Google Play), where many casesof apps infected with malwares and spywares have

• H. Bagheri is with both the department of Computer Science at GeorgeMason University and the Computer Science and Artificial IntelligenceLaboratory at MIT. E-mail: [email protected]

• A. Sadeghi, J. Garcia and S. Malek are with the Department ofComputer Science, George Mason University, Fairfax, VA, 22030.E-mail: {asadeghi,jgarci40,smalek}@gmu.edu

been reported [1]. Numerous culprits are at play here,and some are not even technical, such as the generallack of an overseeing authority in the case of openmarkets and inconsequential implication for thosecaught provisioning applications with vulnerabilitiesor malicious capabilities.

In this context, Android’s security has been athriving subject of research in the past few years.Leveraging program analysis techniques, these re-search efforts have investigated weaknesses from var-ious perspectives, including detection of informationleaks [2]–[4], analysis of the least-privilege princi-ple [5], [6], and enhancements to Android protectionmechanisms [7]–[9]. The majority of these approaches,however, are subject to a common limitation: they areintended to detect and mitigate vulnerabilities in asingle app, but fail to identify vulnerabilities that arisedue to the interaction of multiple apps. Vulnerabili-ties due to the interaction of multiple apps, such ascollusion attacks and privilege escalation chaining [5],cannot be detected by techniques that analyze a singleapp in isolation. Thus, security analysis techniquesin such domains need to become compositional innature.

This paper contributes a novel approach, calledCOVERT, for compositional analysis of Android inter-app permission leakage vulnerabilities. Unlike allprior techniques that focus on assessing the securityof an individual app in isolation, our approach has thepotential to greatly increase the scope of applicationanalysis by inferring the security properties from indi-vidual apps and checking them as a whole by meansof formal analysis. This, in turn, enables reasoning




about the overall security posture of a system (e.g.,a phone device) in terms of the security propertiesinferred from the individual apps.

COVERT combines static analysis with formal meth-ods. At the heart of our approach is a modularstatic analysis technique for Android apps, designedto enable incremental and automated checking ofapps as they are installed, removed, or updated onan Android device. Through static analysis of eachapp, our approach extracts essential information andcaptures them in an analyzable formal specificationlanguage. These formal specifications are intention-ally at the architectural level to ensure the techniqueremains scalable, yet represent the true behavior ofthe implemented software, as they are automaticallyextracted from the installation artifacts. The set ofmodels extracted in this way are then checked as awhole for vulnerabilities that occur due to the interac-tion of apps comprising a system. COVERT uses Alloyas a specification language [10], and the Alloy Analyzeras the analysis engine. Alloy is a formal specificationlanguage based on first order logic, optimized forautomated analysis.

Since COVERT’s analysis is compositional, it pro-vides the analysts with information that is signifi-cantly more useful than what is provided by priortechniques. Our experiences with a prototype imple-mentation of the approach and its evaluation againstone of the most prominent inter-app vulnerabilities,i.e. privilege escalation, in the context of hundredsof real-world Android apps collected from varietyof repositories have been very positive. The results,among other things, corroborate its ability to findvulnerabilities in bundles of some of the most popularapps on the market.

Contributions. This paper makes the following con-tributions:• Formal model of Android framework: We develop a

formal specification representing the behavior ofAndroid apps that is relevant for the detection ofinter-app permission leakage vulnerabilities. Weconstruct this formal specification as a reusableAlloy module to which all extracted app modelsconform.

• Modular analysis: We show how to exploit thepower of our formal abstractions by building amodular model extractor that uses static analysistechniques to automatically extract formal speci-fications (models) of apps form their installationartifacts.

• Implementation: We develop a prototype imple-mentation on top of our formal framework forcompositional security analysis of Android apps.

• Experiments: We present results from experimentsrun on over 500 real-world apps, corroborat-ing COVERT’s ability in effective compositionalanalysis of Android inter-app permission leakagevulnerabilities in the order of minutes.

Outline. The remainder of this paper is organizedas follows. Section 2 provides the background knowl-edge required to understand the contributions of ourwork. Section 3 motivates our research through anillustrative example. Section 4 provides an overviewof COVERT. Sections 5 and 6 describe the details ofmodel extraction and formal analysis, respectively.Section 7 presents the evaluation of the research.Finally, the paper concludes with a discussion oflimitations, and an outline of the related research andfuture work.

2 ANDROID OVERVIEWThis section provides an overview of the Androidapplication framework to help the reader follow thediscussions that ensue.

Application Components. Components are basiclogical building blocks of Android applications. Eachcomponent can be run individually, either by its em-bodying application or by system upon permitted re-quests from other applications. Android applicationscan comprise four types of components: (1) Activitycomponents provide the basis of the Android userinterface. Each Application may have multiple Activ-ities representing different screens of the applicationto the user. (2) Service components provide back-ground processing capabilities, and do not provideany user interface. Playing a music and downloadinga file while a user interacts with another applica-tion are examples of operations that may run as aService. (3) Broadcast Receiver components respondasynchronously to system-wide message broadcasts.A receiver component typically acts as a gatewayto other components, and passes on messages toActivities or Services to handle them. (4) ContentProvider components provide database capabilities toother components. Such databases can be used forboth intra-app data persistence as well as sharing dataacross applications.

Inter-Process Communication. As part of its pro-tection mechanism, Android insulates applicationsfrom each other and system resources from appli-cations via a sandboxing mechanism. Such applica-tion insulation that Android depends on to protectapplications requires interactions to occur througha message passing mechanism, called inter-processcommunication (IPC). IPC is conducted by means ofIntent messages. An Intent message is an event foran action to be performed along with the data thatsupports that action. Component invocations comein different flavors, e.g., explicit or implicit, intra- orinter-apps, etc. Android’s IPC allows for late run-timebinding between components in the same or differentapplications, where the calls are not explicit in thecode, rather made possible through event messaging,a key property of event-driven systems.

Application Configuration. Each Android applica-tion must declare upfront its configuration. Among




other things, it describes the principal componentsthat constitute the application, along with their typesand capabilities. Component capabilities are specifiedas a set of Intent Filters that represent the kinds ofrequests a given component can respond to. Suchhigh-level application descriptions are documented ina separate XML file, called manifest, that accompaniesthe application.

Permissions. Enforcing permissions is the othermechanism, besides sandboxing, provided by the An-droid framework to protect applications, by whichrestrictions are placed on the specific operations thatan application can perform, such as interacting withthe system APIs and databases, as well as cross-application interactions. Each application must de-clare upfront as part of its manifest the permissionsit requires, and the Android system prompts theuser for consent during the application installation.Should the user refuse granting the requested per-missions to an application, the application installationis canceled. No dynamic mechanism is provided byAndroid for granting permissions after applicationinstallation. The manifest file also declares permis-sions enforced by the application or by any of itscomponents; the other applications thus must havethose permissions in order to interact with such pro-tected components. Android platform provides over130 pre-defined permissions, and applications canalso define their own permissions. Each permission isspecified by a unique label, typically indicating theprotected action. For instance, the permission labelof android.permission.SET_WALLPAPER is re-quired for an application to change the wallpaper. TheAndroid permission mechanism has proved insuffi-cient to prevent security violations, since permissionsmay be misused, intentionally or unintentionally, asillustrated in the next section.

3 MOTIVATING EXAMPLE

To motivate the research and illustrate our approach,we provide an example of a vulnerability patternhaving to do with Inter-Process Communication (IPC)among Android apps. Android provides a flexiblemodel of IPC using a type of application-level mes-sage known as Intent (cf. Section 2). A typical appis comprised of multiple processes (e.g., Activity,Service) that communicate using Intent messages. Inaddition, under certain circumstances, an app’s pro-cesses could send Intent messages to another app’sprocesses to perform actions (e.g., take picture, sendtext message, etc.). As an example, Listing 1 showsCallerActivity belonging to a malicious app sending anIntent message to PhoneActivity (Listing 2) belongingto a vulnerable app for placing a call to a premium-rate telephone number.

The vulnerability occurs on line 30 of Listing 2,where PhoneActivity initiates a system Intent of type

1 public c l a s s C a l l e r A c t i v i t y extends A c t i v i t y {2 public void onCreate ( Bundle s a ve d I n s t an c e S t a te ) {3 . . .4 S t r i n g a c t i o n ;5 i f ( selectedMenu == 1)6 a c t i o n = ”PHONE CALL” ;7 e lse8 a c t i o n = ”PHONE TEXT MSG” ;9 btnOK = ( Button ) findViewById (R . id . btnOK ) ;

10 btnOK . se tOnCl ickLis tener (new OnClickListener ( ) {11 public void onClick ( View v ) {12 I n t e n t i n t e n t = new I n t e n t ( a c t i o n ) ;13 i n t e n t . setClassName ( ”com . phoneservice ” , ”com .

phoneservice . PhoneActivity ” ) ;14 i n t e n t . putExtra ( ”PHONE NUM” , ”900−512−1677” ) ;15 s t a r t A c t i v i t y ( i n t e n t ) ;16 }17 }18 }

Listing 1: Malicious app: sends an Intent to call apremium-rate phone number.

1 public c l a s s MainActivity extends A c t i v i t y {2 public void onCreate ( Bundle s a ve d I n s t an c e S t a te ) {3 . . .4 I n t e n t i n t e n t = new I n t e n t ( this , PhoneActivity .

c l a s s ) ;5 s t a r t A c t i v i t y ( i n t e n t ) ;6 }7 }89 public c l a s s PhoneActivity extends A c t i v i t y {

1011 public void onCreate ( Bundle s a ve d I n s t an c e S t a te ) {12 . . .13 I n t e n t i n t e n t = g e t I n t e n t ( ) ;14 S t r i n g number = i n t e n t . g e t S t r i n g E x t r a ( ”PHONE NUM” ) ;15 // i f ( hasPermission ( ) )16 makePhoneCall ( number ) ;17 e lse18 . . .19 }2021 boolean hasPermission ( ) {22 i f ( checkCal l ingPermiss ion ( ” android . permission .

CALL PHONE” ) ==PackageManager .PERMISSION GRANTED)

23 return true ;24 return f a l s e ;25 }2627 void makePhoneCall ( S t r i n g number ) {28 I n t e n t c a l l I n t e n t = new I n t e n t ( I n t e n t .ACTION CALL) ;29 c a l l I n t e n t . setData ( Uri . parse ( number ) ) ;30 startActivity (callIntent); // privilege escalation vulnerability31 }32 }

Listing 2: Vulnerable app: receives an Intent andmakes a phone call.

ACTION_CALL, resulting in a phone call. This is a re-served Android action that requires special access per-missions to the system’s telephony service. AlthoughPhoneActivity has that permission, it also needs to en-sure that the sender of the original Intent message hasthe required permission to use the telephony service.An example of such a check is shown in hasPermissionmethod of Listing 2, but in this particular example itdoes not get called (line 15 is commented) to illustratethe vulnerability. If CallerActivity does not have thepermission to make phone calls (i.e., it is not specifiedin the corresponding app’s manifest file), it is able to




Fig. 1: Overview of COVERT.

make PhoneActivity perform that action on its behalf.This is a privilege escalation vulnerability and hasbeen shown to be quite common in the apps onthe market [2]. It could be exploited by a malwarerunning on the same phone to call premium-ratenumbers.

The above example points to one of the most promi-nent inter-app vulnerabilities, i.e. privilege escalation,that we take as a running example from a class ofvulnerabilities that require compositional analysis tobe able to detect effectively.

4 APPROACH OVERVIEW

This section overviews our approach to automaticallyidentify such vulnerabilities that occur due to the in-teraction of apps comprising a system, and determinewhether it is safe for a bundle of apps, requiringcertain permissions and potentially interacting witheach other, to be installed together. As depicted inFigure 1, COVERT consists of two parts: (1) Model Ex-tractor that uses static code analysis techniques to elicitformal specifications (models) of the apps comprisinga system as well as the phone configuration; and (2)Formal Analyzer that is intended to use lightweightformal analysis techniques to verify certain properties(e.g., known security vulnerability patterns) in theextracted specifications.

COVERT relies on two types of models: 1) appmodel that Model Extractor generates automaticallyfor each Android app; 2) Android framework spec. thatdefines a set of rules to lay the foundation of Androidapps, how they behave (e.g., application, component,messages, etc.), and how they interact with each other.The framework specification is constructed once for agiven platform (e.g., version of Android) as a reusablemodel to which all extracted app models must con-form. It can be considered as an abstract specificationof how a given platform behaves.

Model Extractor takes as input a set of Androidapplication package archives (APK files1). To generatethe app models, it first examines the application man-ifest file to determine its architectural information.

1. APKs are Java bytecode packages used to distribute and installAndroid applications.

Besides such high-level, architectural information col-lected from the manifest file, Model Extractor utilizesstatic analysis techniques to extract other essentialinformation from the application bytecode. We havebuilt a prototype implementation of the model extrac-tor component on top of Soot [11] for static analysisand Dexpler [12] for reverse engineering Android APKfiles. As a result, our prototype implementation ofthe approach only requires the availability of Androidexecutable files, and not the original source code.COVERT, thus, can be used not only by developers,but also by end-users as well as third-party reviewersto assess the trustworthiness of their mobile devices.

The set of app models extracted in this way arethen combined together with a formal specification ofthe application framework, and checked as a wholefor vulnerabilities that occur due to the interactionof apps comprising a system. Finally, a report isreturned to the user describing the list of detectedvulnerabilities. Upon reviewing the report, end-usersand third-party reviewers may choose to protect theirdevices in a variety of ways, e.g., by disallowing theinstallation of certain combination of apps, or dynam-ically restricting certain inter-app communications.

In this research work, we rely on lightweight formalanalysis techniques [13] for modeling and verifica-tion purposes. Such lightweight, yet formally-precisemethods, bring fully automated analysis techniquesto partial models that represent the key aspects ofa system [14]. The analysis is accordingly conductedby exhaustive enumeration over a bounded scopeof model instances. These methods thus facilitateapplication of formal analyzers in development ofsoftware-intensive systems. In our prototype tool im-plementation, we use Alloy [10], as the specificationlanguage, and the Alloy Analyzer as the analysisengine. Alloy is a formal specification language basedon first order logic, optimized for automated analysis.

Our approach can be applied in an offline settingto determine if a particular configuration for a systemcomprised of several apps harbors security vulner-abilities. Although not the focus of this paper, webelieve the approach could also be applied at runtimeto continuously verify the security properties of anevolving system as new apps are installed, and oldones are updated and removed.




In the following two sections, we describe thedetails of static analysis used to capture essentialapplication information and formal analysis for veri-fication.

5 MODEL EXTRACTORIn order to automatically analyze vulnerabilities, wefirst need a model of each application that wouldallow us to determine the potential inter-process com-munications and to also reason about the securityproperties. In our approach, an app model is com-posed of the information extracted from two sources:manifest file and bytecode. This section first formallydefines the model we extract for each app, and thendescribes the extraction process.

Definition 1. A model for an Android application is atuple A =< C, I, F, P, S >, where

• C is a set of components, where each componentc ∈ C has a set of Intent messages intents(c) ⊆ I ,a set of Intent filters ifilters(c) ⊆ F , a set ofpermissions perms(c) ⊆ P required to access thecomponent c, and a set of sensitive (i.e., securityrelevant) paths paths(c) ⊆ S. Each component isdefined as one of the four Android pre-definedcomponent types: Activity, Service, Broadcast Re-ceiver, and Content Provider.

• I is a set of event messages that can be used forboth inter- and intra-app communications. EachIntent i ∈ I has a sender component sender(i) ∈C, may have a recipient component, and threesets of action(i), data(i) and categories(i), spec-ifying the general action to be performed inthe recipient component, additional informationabout the data to be processed by the action,and the kind of component that should handlei, respectively. If the set component(i) is non-empty, the Intent i is called an explicit Intent, asthe recipient component is given explicitly.

• F is a set of Intent Filters, where each filterifilter ∈ F is attached to a component c ∈ C, anddescribes an interface (capability) of c in termsof Intents that it can handle. Each ifilter has anon-empty set of actions(ifilter) and two sets ofdata(ifilter) and categories(ifilter).

• P is a union of required and enforced permis-sions, P = PReq ∪ PEnf , where PReq specifies thepermissions to which the application needs tohave access to run properly and PEnf specifies thepermissions required to access components of theapplication under consideration. We let the set ofpermissions actually used within a component cas permUsed(c) ⊆ PReq .

• S is a finite set of vulnerable paths; each path be-longs to a component c ∈ C, and is represented asa tuple < Entry,Destination >, where Entry andDestination represent either permission-requiredAPIs or IPC calls.

As shown in Algorithm 1, the Model Extractorperforms three major steps to obtain a model of An-droid app: Entity Extraction and Resolution (lines 4–13),Control Flow Augmentation (lines 14–16), and VulnerablePaths Identification(line 17). In the first step, the entitiesare extracted from either the manifest file or thebytecode. Second, COVERT builds an inter-proceduralcontrol-flow graph augmented to account for implicitinvocations. The generated inter-procedural control-flow graph is further annotated with permissions re-quired to enact Android API calls and Intents. Finally,in the last step, a reachability analysis is performedover the generated graph to determine the exposedcomponents that contain unguarded execution pathsreaching permission-required functionalities.

Details of each step, elaborated by Algorithms 2 and3, are discussed in the rest of this section. To helpexplain the approach, Figure 2 illustrates the stepsof applying our model extraction to the motivatingexample (cf. Section 3).

Algorithm 1: Model ExtractorInput: app: Android AppOutput: A: App’s Extracted Model

1 A←< {}, {}, {}, {}, {} >2 ICFG← {}3 summaries← {}// I Entity Extraction - cf. Sec. 5.1

4 A.C ← extractManifestComponents(app)5 A.P ← extractManifestPermissions(app)6 A.F ← extractManifestFilters(app)7 IFEntities ← {}8 foreach method ∈ app do9 IFEntities ← identifyIFEntity(method, summaries)

10 end11 resolveIFEntityAttr(IFEntities)12 A.I ← getIntents(IFEntities)13 A.F ← getIntentF ilters(IFEntities) ∪A.F

// I ICFG Augmentation - cf. Sec. 5.214 G← constructICFG(app)15 E ← extractImplicitCallBacks(app)16 ICFG← augmentICFG(G,E)

// I Vul. Paths Identification - cf. Sec. 5.317 A.S ← findVulPaths(A.C, ICFG)

5.1 Entity Extraction and ResolutionAs part of the entity extraction process, the ModelExtractor first identifies the entities comprising theapp by parsing and examining the app’s manifestfiles. As shown in Algorithm1 (lines 4–6), it can read-ily obtain information such as the app’s components(C) and their types, permissions that the app requires(PReq), and the enforced permissions (PermsEnf ) thatthe other apps must have in order to interact withthe app components. It also identifies some of thepublic interfaces exposed by each application, whichare essentially entry points defined in the manifestfile through Intent Filters (F ) of components. How-ever, not all entry points can be extracted from themanifest file, as discussed further below. Figure 2ashows the entities extracted at this stage of analysis




corresponding to our running example from Section 3.Although the figure depicts the entities extracted forboth apps, the reader should note that in practiceCOVERT’s program analysis runs separately on eachapp, the results of which are then transformed intoseparate formal specification modules, as detailed inSection 6.

After collecting these entities through examiningthe application manifest file, the Model Extractoridentifies complementary information latent in theapplication bytecode. In particular, we also need toextract Intents and Intent Filters, which may be de-fined programmatically in the bytecode, rather thanin the manifest file. Intent Filters for components oftype Service and Activity must be declared in theirmanifest, but for Broadcast Receivers, though, eitherin the manifest or at runtime.

For each method in an app’s component, the al-gorithm detects and extracts Intents and Intent Fil-ters, as shown in lines 8–10. Android API referencedocumentation [15] is used in this step to associatespecific entities to framework-provided APIs definingor manipulating these entities. In the motivating ex-ample (Section 3), samples of entities are identifiable:an Intent entity is created in line 12 of Listing 1;the framework API getIntent is called in line 13 ofListing 2.

Intents and Intent Filters extracted this way needto be further analyzed to obtain additional infor-mation about their attributes. To that end, ModelExtractor iterates over each method of the app andcalls identifyIFEntity, which applies a summary-based iterative data-flow analysis [16] to detect en-tities and their attributes. For each Intent message,for example, it tracks the message’s sender, the targetcomponent, the type of action it has (if any), data to beprocessed by the action, and categories of componentsthat should handle the Intent. Note, however, that thevalues of attributes are resolved through an additionalanalysis described later in this section.identifyIFEntity computes a method summary

for each analyzed method. The method summarydescribes information about entities that can be in-ferred from a method. Method summaries make entityresolution inter-procedural, allowing an entire app tobe analyzed. Methods are analyzed in reverse topo-logical order with respect to the app’s call graph sothat a given method’s summary is computed beforeany methods that call it are analyzed. Cycles in thecall graph (e.g., from recursion) are handled in thestandard manner, by treating the involved methodsas one “super method.”

The details of identifyIFEntity are shown inAlgorithm 2. identifyIFEntity outputs the setIFEntities , which contains identified Intents and In-tent Filters that are defined and utilized in the An-droid app’s source code. There are four types ofstatements that need to be considered to retrieve

Fig. 2: Extracted models for the apps described inListings 1 and 2 at different steps of analysis.

entity properties: (1) statements that create an entity,(2) statements that set the attributes of an entity, (3)statements that consume an entity, and (4) statementsthat invoke non-Android API methods.

The first type of statement, handled in lines 10–15of Algorithm 2, correspond to the APIs creating anentity (e.g., through the constructors). In this case, thenewly-created entity is added to the gen set in orderto be used in the other cases; any entities that arereassigned are added to the kill set to prevent further




propagation of such entities; and IFEntities is updatedwith the new entity.

The second type of statement, handled by the caseof lines 16–19, are the ones that set the attributesof the entity under consideration (i.e., the action,category, data, and target attributes). For example,Intent.setClassName() sets the target compo-nent for the given Intent.

The third type of statement, handled in lines 20–23of Algorithm 2, correspond to the APIs that consumeentities. Entities are consumed in different ways. AnIntent, for example, is consumed when it is sent toa component: startActivity(Intent) launches anew Activity by sending an Intent that carries theActivity’s description. An Intent Filter, however, isconsumed when it is used in registering a BroadcastReceiver. Since the attributes of an entity cannot beset after consumption, the consumed entity is addedto the kill set.

Finally, for method calls that are not part of theAndroid API, identifyIFEntity utilizes the sum-mary of an invoked method to determine the en-tities and their attributes that are computed in themethod (lines 24–26 of Algorithm 2). In particular,identifyIFEntity utilizes the summary of themethod invoked in the program statement stmt underanalysis to update the gen, kill, and IFEntities sets.For example, in line 16 of Listing 2, the non-AndroidAPI method makePhoneCall is invoked, where anew Intent is created with action and data attributes.identifyIFEntity utilizes the method summaryfor makePhoneCall to determine that the invocationof that method results in the creation of a new Intentwith action ACTION CALL and a data attribute. Inthis case, updateFromSummary adds this new Intentto the gen and IFEntities sets so that the new Intentis recorded and will be propagated by the data-flowanalysis. The kill set is not modified in this case sincethe new Intent is not assigned to an already-definedIntent reference.

For aliasing in the case of entities and their at-tributes, we utilize class hierarchy analysis [16], whichproduces accurate results for our purposes (as shownin Section 7). However, our algorithm can subsitutethe class hierarchy analysis for a more precise anal-ysis (e.g., a points-to analysis), possibly trading offefficiency for precision.

The overall algorithm (line 11 of Algorithm 1) thencalls resolveEntityAttr to resolve the values as-sociated with the retrieved entity attributes (e.g., theaction, categories, and data types of Intents). To dothis, it uses string values obtained from string con-stant propagation [16], which provides a precise solu-tion since, by convention, Android apps use constantstrings to define these values. In cases where a stringvariable’s value cannot be determined statically, wetake a conservative approach and assume the value tobe any string. Despite this conservative approach, our

Algorithm 2: identifyIFEntityInput: method, summariesOutput: IFEntities

1 IFEntities ← {}2 gen[entry]← {entities passed as parameters to method}3 workList← {all statements of method}4 repeat5 stmt← workList.head6 foreach stmt′ ∈ pred(stmt) do7 in[stmt]← in[stmt] ∪ out[stmt′]8 end9 switch stmt.type do

10 case Intent or Intent Filter Constructors11 entity ← corresponding entity of statement12 gen[s]← {entity}13 kill[s]← set of reassigned entities14 IFEntities ← {entity} ∪ IFEntities15 end16 case Entity Attribute Assignment17 entity ← corresponding entity of statement;18 updateAttr(entity)19 end20 case Intent Sender or Intent Filter Registration21 entity ← corresponding entity of statement22 kill[s]← {entity}23 end24 case Non-Android API Method Call25 updateFromSummary(gen, kill, IFEntities ,

summaries)26 end27 endsw28 prevOut← out[stmt]29 out[stmt]← (in[stmt] \ kill[stmt) ∪ gen[stmt]30 if prevOut 6= out[stmt] then31 workList← workList ∪ succ(stmt)32 until workList = ∅;33 summarize(gen, kill, IFEntities , summaries)

evaluation results (see Section 7) show our techniqueto be significantly precise, while remaining scalable.

It is also possible that a property is disambiguatedto more than one value. For instance, consider ourrunning example, the Intent action could be as-signed to two different values at runtime, namely“PHONE_CALL” and “PHONE_TEXT_MSG” defined onlines 6 and 8 of Listing 1, respectively. We take aconservative approach to handle such an issue andgenerate a separate entity for each of these values, asthey contribute different exposure surfaces or eventmessages in the case of Intent Filters and Intents,respectively.

Figure 2b shows the extracted model correspondingto our running example (recall Section 3) at this stageof analysis. In this particular example, Intents, aswell as their properties (not depicted), are the onlyadditional entities extracted from the bytecode. Forclarity of presentation, Figure 2b only depicts theIntents relevant to the vulnerability in our example.

5.2 Control Flow AugmentationSubsequent to extracting entities, Model Extractorneeds to determine control flow between methods inorder to detect vulnerabilities for privilege escalation.To that end, Model Extractor constructs an inter-procedural control-flow graph (ICFG) of the entire




application. An ICFG is a collection of control-flowgraphs (CFGs) connected to each other at call sites.

However, due to the event-driven structure of theAndroid platform, the traditional ICFG generationmethods do not connect CFGs at call sites corre-sponding to implicit invocations. To generate an ICFGthat takes implicit invocation into account, we needto include call-backs of an app. These are Android-API methods that no other part of the applicationexplicitly invokes.

To connect the CFGs over implicit calls, we tra-verse the nodes of each CFG in a depth-first man-ner, and connect all implicit invocation nodes withthe corresponding call-back nodes. For example, inlines 11–15 of Listing 1, an anonymous inner-classis defined within the onCreate method to han-dle the Click events triggered by the btnOk button.Thus, an edge is added to the app’s ICFG from thesetOnClickListener invocation to the entry pointof onClick.

Figure 2c shows some parts of ICFGs extracted foreach of the apps from Section 3. Here, the dashedline between nodes M© and N© indicates an implicitinvocation.

5.3 Vulnerable Paths Identification

The last step is to determine if there is a path fromeach component’s IPC entry point to an invocationof a permission-required functionality that is eitherinappropriately-guarded or unguarded, which maylead to IPC vulnerabilities. For this purpose, COVERTleverages the reachability analysis described in Algo-rithm 3.

Here, the entry nodes are IPC calls, which rep-resent methods in a component that handle Intentsgenerated by other components or the Android frame-work itself. Specifically, all app components, includingActivities and Services, are required to follow pre-specified lifecycles [17] managed by the framework inan event-driven manner. Each component, thus, regis-ters event handlers that serve as the IPC entry pointsthrough which the framework starts or activates thecomponent once handled events occur. An Activity,for example, generates a StartActivity event thatresults in another Activity’s onCreate() method tobe called. Moreover, for each entry node, the corre-sponding component definition in the manifest file isalso examined to ensure the component is public (line5 of Algorithm 3). Recall from Section 2, a componentis public, if its specification sets the EXPORTED flag ordeclares Intent filter(s).

The destination nodes are defined as permission-required API calls or Intent messages that are notproperly checked. As shown in lines 7–11, to de-termine destination nodes, for each node in ICFG,tagCheckedPerm marks it with two tags: (1) Reqprmtag denotes that a statement is called at the node

Algorithm 3: findVulPathsInput: C: set of Components, ICFGOutput: Vulnerable Paths

1 Entry ← {}2 Dest← {}3 foreach c ∈ C do4 if isPublic(c) then5 Entry ← Entry ∪ getEntryPoints(c)6 end7 foreach n ∈ ICFG do8 tagCheckedPerm(n)9 if n.hasTag(Reqprm) ∧ !n.hasTag(Checkprm) then

10 Dest← Dest ∪ n11 end12 return pathFinder(Entry,Dest, ICFG)

under consideration that requires a particular permis-sion of “prm”; and (2) Checkprm tag shows the nodeis guarded by permission “prm” checking. Thus, avulnerable destination node is a node tagged withReqprm but not with the corresponding Checkprm tag.

To identify Reqprm tags, tagCheckedPerm usesAPI permission maps available in the literature, and inparticular the PScout permission map [18], one of themost recently updated and comprehensive permissionmaps available for the Android framework. PScoutspecifies mappings between Android API calls/In-tents and the permissions required to perform thosecalls. The nodes tagged as permission-required aredistinguishable in Figure 2d by ! sign. For example,node F© is a tagged node as it uses Telephony API thatrequires CALL_PHONE permission.

Identifying and applying Checkprm is trickier, sincepermission enforcement for a component could bedefined at two levels. While the coarse-grained per-missions specified in the manifest file are enforcedover a whole component, a developer can also addpermission checks throughout the code controllingaccess to particular aspects of a component. The for-mer can be readily checked using the informationextracted from the manifest file (recall Section 5.1),but the latter requires further program analysis.

To determine permission-check API invocationsthat act as guards in code, tagCheckedPerm lever-ages a context-sensitive analysis (i.e., it considers thecalling context of a method call) that handles the twomost common cases. The first case occurs when apermission-check API is called directly. For the secondcase, tagCheckedPerm determines if a statementinvokes a method that results in a call to a permission-check API (e.g., the commented permission check online 15 of Listing 2). To handle aliasing in this case,tagCheckedPerm utilizes class hierarchy analysis,which has proven sufficiently precise for our pur-poses.

Once entry and destination nodes are identified,findVulPaths determines the paths between them (line12 of Algorithm 3). To achieve high precision in de-termining paths between entry and destination nodes,our approach is context-sensitive. In the interest of




scalability, COVERT’s analysis, however, is not path-sensitive (i.e., the analysis does not distinguish in-formation obtained from different paths). The results(see Section 7) indicate no significant imprecisioncaused by path-insensitivity in the context of Androidvulnerability analysis.

Components that contain an entry → destinationpath, returned by findVulPaths, are vulnerable to var-ious inter-app attacks. For instance, in Figure 2d thered-colored path of < A©, B©, D©, F© > is vulnerable, asthere is a path from an entry node A© to an invocationof a permission-required API (i.e., Telephony API).As shown in Listing 1, a malicious app can exploitthis vulnerability and call the Telephony API withouthaving the proper privilege.

To achieve scalable, yet precise alias analysis foridentifying vulnerable paths, we perform an on-demand alias analysis [19]. More specifically, insteadof applying the analysis to all variables, only thevariables utilized at statements invoking source orsink methods are considered for analysis duringvulnerable-path identification.

The Model Extractor produces an extended-manifest file for each Android application. Thisextended-manifest, documented in an XML format,encompasses all information extracted from both theapp bytecode as well as the app manifest file. Oncean app model is extracted, it can then be reused foranalysis within several bundles of apps. Given a set ofextended-manifest files corresponding to a bundle ofapps, COVERT generates a package of Alloy modules,which in turn enables their compositional analysis.The next section details the structure of generatedAlloy models.

6 FORMAL ANALYZER

In this section we show that our ideas for compo-sitional, formal, and automated analysis of Androidapps can be reduced to practice. Our approach au-tomatically transforms the models derived throughstatic analysis into an analyzable specification lan-guage, and verifies them against certain propertiesusing the automated analyzers associated with suchlanguages. As an enabling technology, we use theAlloy language [10], to represent a model of Androidframework, application models, and to-be-analyzedproperties.

There are four main reasons that motivate ourchoice of Alloy for this work. First, its comprehen-sible, object-oriented-like syntax, backed with logicaland relational operators, makes Alloy an appropriatelanguage for declarative specification of both appli-cations and properties to be checked (i.e., assertions).Second, its ability to automatically analyze specifica-tions with no custom programming is useful as anautomation mechanism.

Third, and more importantly, its effective modulesystem allows us to split the overall, complicated sys-tem model among several tractable modules. A simplemodule system is not only convenient, but is animportant part of our approach, as it enables effectivecompositional analysis of, among other things, im-penetrable scenarios, where for example a maliciousapp can leverage a chain of vulnerable componentsto leak sensitive data or to perform actions that arebeyond its individual privileges. Android apps andproperties to be checked are strictly separated andmodularized in different specifications, which furtherfacilitates reusability of such specifications, and thisis clearly where much of the power of our workcomes from. Specifically, Android framework speci-fication, application specifications, and specificationsof vulnerabilities to be analyzed are all reusable, andthis paper shows the promise of paying a one-timecost to formally specify them to enable compositionalanalysis of Android vulnerabilities.

Lastly, the extraction approach we take in COVERTto generate bundle specifications is incremental. Morespecifically, the Model Extractor produces a separateextraction-output file for each Android application,independent of other apps in the bundle. The set ofextracted app models are then combined together tocheck for inter-app vulnerabilities. Hence, once an appmodel is extracted, it can then be reused for analysiswithin several bundles of apps. That means to add,update or remove an app from the bundle, we onlyneed to add, update, or remove information for thatparticular app.

To appreciate COVERT’s approach, consider thatan alternative approach is to detect the inter-appvulnerabilities by performing the program analysison a whole set of apps simultaneously. But suchan approach suffers from two shortcomings. First,it would face serious scalability issues, as a typicalmobile device may have tens or hundreds of appsinstalled on it, and the analysis space grows expo-nentially with the number of apps to-be-analyzed.Second, it would require such a complex analysis tobe performed every time any of the apps are updated,added, and removed. COVERT does not suffer fromthe same shortcomings because it analyzes the apps inisolation, and relies on the declarative power of formalspecification languages (namely Alloy) to separatethe various models needed for the analysis, therebyfacilitating reuse of the models as well as the results.

In the rest of this section, we first provide a briefoverview of Alloy, and then describe how we use itin modeling and thereby analysis of Android applica-tions.

6.1 Alloy Overview

Alloy is a formal modeling language with a compre-hensible syntax that stems from notations ubiquitous




in object orientation, and semantics based on the first-order relational logic [10]. The Alloy Analyzer is aconstraint solver that supports automatic analysis ofmodels written in Alloy. The analysis process is basedon a translation of Alloy specifications into a Booleanformula in conjunctive normal form (CNF), which isthen analyzed using off-the-shelf SAT solvers.

The analyzer provides two types of analysis: Sim-ulation, in which the analyzer demonstrates consis-tency of model specifications by generating a sat-isfying model instance; and Model Checking, whichinvolves finding a counterexample—a model instancethat violates a particular assertion. We use the formerto compute model instances, represented as satisfy-ing solutions to the combination of models capturedfrom app implementations. This shows the validity ofsuch extracted models, confirming that the capturedmodels are self-consistent, mutually compatible andconsistent with the Android specifications modeled ina separate module. The latter is used to verify securityproperties of interest within the models.

The Alloy Analyzer is a bounded checker, so acertain scope of instances needs to be specified. Thescope, for example, states the number of app com-ponents. The analysis is thus performed through ex-haustive search for satisfying instances within thespecified scopes. As a result, the analyzer is soundand complete within such scopes. To take advantageof partial models, the latest version of the analyzeruses KodKod [20] as its constraint solver so that itcan support incremental analysis of models as theyare constructed. The generated instances are thenvisualized in different formats such as graph, treerepresentation or XML.

The essential constructs of the Alloy modeling lan-guage include: Signatures, Facts, Predicates, Functionsand Assertions. Signatures provide the vocabulary ofa model by defining the basic types of elements andthe relationships between them. Facts are formulasthat take no arguments, and define constraints thatany instance of a model must satisfy. Predicates areparameterized and reusable constraints that are al-ways evaluated to be either true or false. Functionsare parameterized expressions. A function similar toa predicate can be invoked by instantiating its pa-rameter, but what it returns is either a true/false ora relational value instead. An assertion is a formularequired to be proved. It can be used to check a certainproperty of a model.

6.2 Formal Model of Android Framework

To carry out the verification analysis, we begin bydefining a common Alloy module, androidDeclaration,that models the Android application fundamentals(e.g., application, component, intent, etc.) and theconstraints that every application must obey. Techni-cally speaking, this module can be considered as a

1 module androidDeclarat ion23 a b s t r a c t s i g Appl icat ion{4 usesPermissions : s e t Permission ,5 appPermissions : s e t Permission6 }7 a b s t r a c t s i g Component{8 app : one Applicat ion ,9 i n t e n t F i l t e r s : s e t I n t e n t F i l t e r ,

10 permissions : s e t Permission ,11 paths : s e t Path12 }13 a b s t r a c t s i g I n t e n t F i l t e r {14 a c t i o n s : some Action ,15 data : s e t Data ,16 c a t e g o r i e s : s e t Category ,17 }18 f a c t I n t e n t F i l t e r C o n s t r a i n t s{19 a l l i : I n t e n t F i l t e r | one i . ˜ i n t e n t F i l t e r s20 no i : I n t e n t F i l t e r | i . ˜ i n t e n t F i l t e r s in Provider21 }22 a b s t r a c t s i g I n t e n t{23 sender : one Component ,24 component : lone Component ,25 a c t i o n : lone Action ,26 c a t e g o r i e s : s e t Category ,27 data : s e t Data ,28 }29 a b s t r a c t s i g Path{30 entry : one Resource ,31 d e s t i n a t i o n : one Resource32 }33 a b s t r a c t s i g Permission{}

Listing 3: Alloy specifications of essential Androidapplication elements.

meta-model for Android applications. It is manuallyconstructed once and does not change, unless thereare substantial changes in the way Android operates.

Listing 3 partially outlines androidDeclaration mod-ule, representing Android application fundamentalsin Alloy. The essential element types (cf. Def. 1) aredefined as top-level Alloy signatures. As mentionedearlier, a signature introduces a basic element typeand a set of its relations, called fields, accompanied bythe type of each field.

There are six top-level signatures to model thebasic element types: Application, Component,IntentFilter, Intent, Path, and Permission.Note that these signatures are defined as abstract,meaning that they cannot have an instance ob-ject without explicitly extending them. Contain-ment relations (e.g., between Applications andPermissions) are defined as Alloy relations.

According to lines 4–5, the Application signa-ture contains two fields of usesPermissions andappPermissions that identify two sets of permis-sions, representing PReq and PEnf , respectively (cf.Def. 1).

The app field within the Component signature (line8) identifies the parent application that a componentbelongs to. The keyword one states that every Com-ponent object is mapped to exactly one Applicationobject. Signature declarations of four core componenttypes, namely Activity, Service, Receiver and Provider,extend the Component signature. In the interest ofspace, their specifications are omitted from Listing 3.




A component may have any number of filters, eachone describing a different interface of the component.Such filters are captured by the intentFiltersfield (line 9). The permissions field represents a setof permissions required to access a component. Thepaths field then indicates vulnerable paths within acomponent.

The IntentFilter signature contains three fieldsof actions, data and categories. The multi-plicity keyword some in Alloy denotes that the de-clared actions relation contains at least one ele-ment, and the keyword set tells Alloy that data andcategories map each IntentFilter object to zeroor more Data and Category objects, respectively.

Properties of the IntentFilter signature are declaredas a fact paragraph (lines 18–21). The ∼ operatordenotes the relational inverse operation, forming anew relation by reversing the order of atoms in eachtuple of the relation. The statement of line 18, thus,states that each IntentFilter belongs to exactlyone Component. Out of four core component types,three of them can define IntentFilters. To excludeContent Providers from having IntentFilters, weadd a separate fact constraint specification, repre-sented in line 20.

The Intent signature contains five fieldsof sender, component, action, data andcategories. The first one denotes the componentsending the intent. The component field identifiesthe recipient component. The keyword lone indicatesthat this element is optional, and an Intent may haveone or no declared recipient component. Recall fromSection 5, if it maps to a non-empty set, the Intentobject is called an explicit Intent. The Android intent-resolver delivers explicit Intents to the designatedcomponent, without considering other informationof the Intent object.

To determine to which component an implicitIntent—one that does not specify any recipientcomponent—should be delivered, three elements ofaction, data, and categories are consulted. Theaction filed names the general action to be per-formed in the recipient component. The data fieldindicates additional information about the data tobe processed by the action, and each Data instanceconsists of both the URI of the data to be acted on andits MIME media type. Finally, the categories fieldindicates the kind of component that should handlethe Intent object. Each of these elements correspondsto a test, in which the Intent’s element is matchedagainst that of the IntentFilter. An IntentFilter mayhave more actions, data, and categories than the In-tent, but it cannot contain less.

We define the entry and destination fields ofthe Path signature based on canonical permission-required resources identified by Holavanalli et al.for Android applications [21]. Examples of entryand destination resources are NETWORK, IMEI, and

Fig. 3: A vulnerability identified by COVERT for theapps described in listings 1 and 2. The red lines andnodes indicate the vulnerable path.

SDCARD. Among others, the permission NETWORK,for example, allows the app to access the Internet,through either WIFI or cellular network. In additionto permission domains, the IPC mechanism augmentsboth entry and destination sets, which allows apps toprovide services to one another. Figure 3 shows a pathidentified in VicApp with an IPC as publicly accessibleentry point.

Finally, the last top-level signature is Permission.COVERT captures both the system-definedpermissions—declared within the system’s AndroidManifest—and application-defined permissions—declared within the application manifest file, anddocuments them as a separate Alloy model sharedbetween Alloy modules of all apps.

6.3 Formal Model of Apps

Three pieces of Alloy specifications are conjoined inthe process of modeling various parts of Androidapps extracted from their APK files. First, a specifi-cation module, called appDeclaration, that documentsbasic element types, such as Action, Category andPermission, shared between Alloy models of all apps.Second, an app model, comprising Components thatconstitute the app, IntentFilters of each Component, aswell as required and enforced Permissions of the app.This model is represented in a separate Alloy modulefor each app. Third, an inter-process communication(IPC) module that models all Intent messages createdwithin the apps under consideration. All these modelsrely on the Android framework specification module,presented in the previous Section.

We use snippets of the running example (cf. Sec-tion 3) to explain each piece of our formal model. Letus begin with the appDeclaration module.




module appDeclarat ion

open androidDeclarat ion

one s i g MAIN extends Action{}one s i g CALL PHONE extends Permission{}. . .

Listing 4: Part of the declaration of basic elementtypes automatically extracted from Android apps.

Consider the portion of the appDeclaration module,shown in Listing 4. At the top, the specification im-ports the Alloy module for the Android framework.It then declares MAIN to be a singleton subset ofAction. Typically, one activity in an app is speci-fied as the “main” activity, declaring it as the mainentry point to the app, and presented to the userwhen launching the app. In a signature declaration,the keyword one specifies the declared signature tocontain exactly one atom, thereby restricting the sig-nature to be unique. This naming scheme allows usto reuse the term MAIN when we want to declare themain activity of each application. The next statementrepresents a permission example declared in a similarway. For the sake of clarity, we use the permissions’shorthand in our Alloy model. For example, here weuse CALL_PHONE to model the particular permissionof android.permission.CALL_PHONE.

Listing 5 partially delineates the generated spec-ification for the malicious app shown in List-ing 1. It starts by importing the appDeclaration mod-ule (line 3), and then the MalApp is declaredas an extension of the Application signature.This app does not declare any permission neitheras required (usesPermissions) nor as enforced(appPermissions). The MalApp has a Componentof type Activity, named CallerActivity, whichdeclares an IntentFilter with MAIN and LAUNCHER

1 module MalApp23 open appDeclarat ion45 one s i g MalApp extends Appl icat ion{}{6 no usesPermissions7 no appPermissions8 }9

10 one s i g C a l l e r A c t i v i t y extends A c t i v i t y{}{11 app in MalApp12 i n t e n t F i l t e r = I n t e n t F i l t e r 113 no permissions14 no paths15 }1617 one s i g I n t e n t F i l t e r 1 extends I n t e n t F i l t e r {}{18 a c t i o n s = MAIN19 c a t e g o r i e s = LAUNCHER20 no data21 }

Listing 5: Part of the generated specification forMalicious app shown in Listing 1.

1 module VicApp23 open appDeclarat ion45 one s i g VicApp extends Appl icat ion{}{6 usesPermissions = CALL PHONE7 no appPermissions8 }9

10 one s i g PhoneActivity extends A c t i v i t y{}{11 app in VicApp12 i n t e n t F i l t e r = I n t e n t F i l t e r 213 no permissions14 paths = path115 }1617 one s i g path1 extends Path{}{18 entry = IPC19 d e s t i n a t i o n = PHONECALL20 }

Listing 6: Part of the generated specification forVictim app shown in Listing 2.

settings, marking it as the main activity of the app.The code snippet of Listing 6 represents the gener-

ated specification for the Victim app shown in List-ing 2. The VicApp has access to the CALL_PHONEpermission (line 6), but declares no permission re-quirement for other apps to access its own Compo-nents (line 7). This app specification then declares thePhoneActivity component, exposing a vulnerablepath (path1) from its entry point to a permissionrequired resource (PHONECALL), as represented inFigure 3.

Application interactions in Android occur throughIntent messages. We record the interactions amongapp Components in a separate Alloy module, calledIPC. The code snippet shown in Listing 7 representspart of the generated specification for the IPC module.After importing modules of the involved apps (lines3–4), the specification in lines 6–12 models the Intentof Listing 1, where the CallerActivity Componentsends an explicit Intent (i.e., intent1 as shown inFigure 3) to the PhoneActivity Component, withspecified action to be performed and with extra data.

1 module IPC23 open VicApp4 open MalApp56 one s i g i n t e n t 1 extends I n t e n t{}{7 sender = C a l l e r A c t i v i t y8 component = PhoneActivity9 a c t i o n = PHONE CALL

10 no c a t e g o r i e s11 extraData = Yes12 }13 . . .

Listing 7: Part of the generated inter-componentcommunication module.

6.4 Checking Android Application ModelsThe previous sections present a formal model ofAndroid framework (Section 6.2), developed as a




reusable Alloy module to which extracted app modelsconform (Section 6.3). Here, we describe the essenceof this work: how one can use the power of pro-posed formal abstractions to perform the composi-tional analysis of Android apps.

To that end, we develop assertions that model a setof security properties required to be checked. Theseassertions express properties that are expected to holdin the extracted specifications. Similar to Androidspecification, vulnerability assertions are manuallyconstructed once and do not change, unless there aresubstantial changes in Android that resolve or modifythe known types of inter-app vulnerabilities.

Considering the privilege escalation, Davi et al. [22]state it as follows: “An application with less permis-sions (a non-privileged caller) is not restricted to accesscomponents of a more privileged application (a privilegedcallee).” Listing 8 formally expresses the privilegeescalation assertion in Alloy. In short, the assertionstates that the dst component (victim) has access toa permission (usesPermission) that is missing inthe src component (malicious), and that permissionis not being enforced in the source code of the victimcomponent, nor by the application embodying thevictim component. Recall from Section 5 that thereare two ways of checking permissions in Android.

1 a s s e r t p r i v i l e g e E s c a l a t i o n{2 no d i s j src , dst : Component , i : I n t e n t |3 ( s r c in i . sender ) &&4 ( dst in s r c . ˆ t r a n s i t i v e I P C ) &&5 ( some p : dst . app . usesPermissions |6 not ( p in s r c . app . usesPermissions ) &&7 not ( ( p in dst . permissions ) | | ( p in dst . app .

appPermissions ) ) )8 }

Listing 8: privilegeEscalation specification in Alloy.

To address a situation, in which more than twocomponents are involved in the privilege escala-tion, the assertion relies on the specification of the

1 fun t r a n s i t i v e I P C : Component −> Component {2 { src , dst : Component | some i : In tent , d : Path |3 ( s r c in i . sender ) &&4 ( dst in i n t e n t R e s o l v e r [ i ] ) && some dst . paths5 }6 }78 fun i n t e n t R e s o l v e r ( i : I n t e n t ) : s e t Component{9 {c : Component | some i . component

10 impl ies {c = i . component}11 e l s e { some f : I n t e n t F i l t e r |12 f . ˜ i n t e n t F i l t e r in c13 && i . a c t i o n in f . a c t i o n s14 && i . c a t e g o r i e s in f . c a t e g o r i e s15 && ( i . data . u r i = f . data . u r i16 && i . data . type = f . data . type ) }17 }18 }

Listing 9: IntentResolver and transitiveIPCspecifications in Alloy.

transitiveIPC function, shown in Listing 9. Theoperator “ˆ” represents transitive closure. The expres-sion src.ˆtransitiveIPC thus represents the setof all components reachable from src following oneor more IPCs. The transitiveIPC itself relies on thespecification of an intentResolver function. TheComponent, Intent and IntentFilter signatures are spec-ified such that they have all the necessary attributesrequired for Intent resolution. We thus describe intent-resolver as a function augmenting the aforementionedandroidDeclaration module. This function takes as in-put an Intent and returns a set of Components thatmay handle the Intent under consideration. Giventhe Intent is explicit, it should be delivered to therecipient identified by the component field of theIntent (line 10). Otherwise, the resolver checks Com-ponents’ IntentFilters to find those whose elementsare matched against the given Intent. Specifically, animplicit Intent must pass a matching test with respectto each of the action, data, and categories elementson the IntentFilters bound to a component (as statedin lines 13–16). Seeing that a component can definemultiple IntentFilters, an Intent that does not matchone of a component’s IntentFilters may match another(lines 11–12).

If an assertion does not hold, the analyzer reportsit as a counterexample, along with the informationuseful in finding the root cause of the violation.Counterexample is a particular model instance thatmakes the assertion false. Given our running example,the analyzer automatically generates the followingcounterexample:

. . . // omitted d e t a i l s of model i n s t a n c e sp r i v i l e g e E s c a l a t i o n s r c ={MalApp/ C a l l e r A c t i v i t y}p r i v i l e g e E s c a l a t i o n d s t ={VicApp/PhoneActivity}p r i v i l e g e E s c a l a t i o n i ={ i n t e n t 1}p r i v i l e g e E s c a l a t i o n p ={appDeclarat ion/CALL PHONE}

It states that the VicApp/PhoneActivity compo-nent has access to the CALL_PHONE permission, andis resolved by the formal analyzer as the receiver ofintent1 (as shown by a dashed line in Figure 3), whichis being sent by the MalApp/CallerActivity com-ponent lacking access to the CALL_PHONE permission.The generated counterexample confirms that the com-position of Victim and Malicious apps could result inprivilege escalation.

7 EMPIRICAL EVALUATIONTo assess the effectiveness of our approach in re-vealing Android inter-app vulnerabilities, we haveconducted an evaluation that addresses the followingresearch questions:

RQ1. What is the importance of this research?To what extent are Android apps overprivi-leged and unsafe due to usage of permission-required APIs?

RQ2. How well does COVERT perform? Does itenable compositional analysis of real-world




Fig. 4: Distribution of apps selected from the GooglePlay repository.

Android apps? How much manual effort isinvolved in the analysis process?

RQ3. What is the overall accuracy of COVERT indetecting inter-app vulnerabilities?

RQ4. How does compositional analysis compareto single app analysis?

RQ5. What is the performance of our prototypetool implemented atop SAT solving tech-nologies and static analyzers?

Our experimental subjects are a set of Androidapps drawn from four different app repositories. Thefirst sample set consists of a snapshot of the top 100popular free apps, available on the Google Play [23]in late November 2013. Our second set of test subjectsis representative of open source apps, and includes300 apps collected from the F-Droid open sourcerepository [24]. To cover the apps available in third-party repositories, we also included 50 apps fromBazaar [25], a local app store, as the third set. Thefourth one is a collection of 50 malicious apps identi-fied by the MalGenome project [26].

Figure 4 illustrates the distribution of apps fromGoogle Play repository that were used in our experi-ments, showing that they are sufficiently diverse, fromdifferent categories, and representative of what onecan find installed on a typical device. For brevity,we do not show the distribution of apps from otherrepositories that have different set of categories, butthe apps selected from these other repositories weresimilarly diverse.

To answer RQ1, we examine all of the aforemen-tioned subject apps, to obtain some evidence as tothe likelihood of encountering privilege escalationvulnerability in the apps that are available in suchmarkets (§ 7.1).

To address RQ2, we partition the set of apps understudy into 10 bundles, each containing 50 apps fromthree repositories, except the last bundle whose appsare only from the open source repository to enablemanual analysis. These bundles simulate collections

of apps installed on end-user devices, and we usethem to conduct 10 independent experiments. We thenreport and analyze the experimental results (§ 7.2).

To evaluate the accuracy of warnings reported byCOVERT (RQ3), we randomly select 50 apps from theF-Droid open source apps and run our prototype toolon them. We then manually analyze each warning todetect the rate of tool error, i.e., false positive (§ 7.3).

To address RQ4 (single vs. compositional app anal-ysis), we adopt a set of practical security rules, calledKirin rules, for Android apps from Enck et al. [6], andformally model each of these rules in such a way thatenables their applications for both “compositional”analysis as well as analysis of each “single” app in iso-lation. We then analyze all the apps in the Malgenomerepository against these rules, and compare the resultsof single and compositional app analysis (§ 7.4).

To address RQ5 (performance benchmarks), wemeasure the computation time required for bothmodel extraction and formal analysis activities (§ 7.5).

We use the COVERT apparatus we developed basedon the approach for carrying out the experiments.COVERT is implemented as a publicly available tool2.We have built a prototype implementation of themodel extractor component on top of the Soot [11]static analysis tools. Soot is developed for analyz-ing Java bytecode [11]. We thus first use the Dex-pler transformer [12] to translate Android’s dalvikbytecode into the Soot’s intermediate representationlanguage, called Jimple. As a result, our prototypeimplementation of the approach only requires theavailability of Android executable files, and not theoriginal source code. COVERT, thus, can be used notonly by developers, but also by end-users as well asthird-party reviewers. The translation of captured appmodels into the Alloy language is implemented usingthe FreeMarker template engine [27].

7.1 Significance of Compositional AnalysisTable 1 outlines the amount of permissions requestedby apps in each repository, along with the fractionof which is actually used through API calls, as wellas enforced—depicted as checked in Table 1—by theapps. Based on the permission map provided by Auet al. [18], we analyzed the fraction of permissionsactually needed for API calls performed by the appsunder consideration (cf. Section 5). The result showsthat overall 32% of acquired permissions are necessaryfor API calls. This confirms previous studies thatshowed many Android apps on the market are over-privileged [5], [18]. Applications having extraneouspermissions violate the least privilege principle. Wealso analyzed what fraction of the obtained permis-sions are checked either within the app manifest fileor throughout the code. The difference between the

2. Research artifacts and experimental data are available athttp://www.sdalab.com/projects/covert




TABLE 1: Summary of statistical information aboutPermissions in subject systems.

PermissionsRepository used checked

1472GPlay 364 156

(%24.7.1) (%10.6)1031

F-Droid 505 77(%49.0) (%7.5)

499MalGenome 100 5

(%20.0) (%1.0)305

Bazaar 105 16(%34.4) (%5.2)

set of used and checked permissions are importantfor privilege escalation. The extraneous permissionsthat result in overprivilege are not susceptible toprivilege escalation, unless they are actually used bythe permission holders. On average, each app hasabout 2 unchecked but used permissions that couldlead to exploitable vulnerabilities. Indeed, such an un-safe use of permission-required APIs may lead to anexploitable vulnerability provided that there is a pathfrom the exported interface of the app component tothe API use. This analysis is the subject of next section.

7.2 Automated Analysis of ApplicationsThe aim of RQ2 is to evaluate the automation levelwhen using COVERT for compositional analysis ofreal-world Android apps, and how much manual ef-fort is involved in the analysis process. To that end, weevaluate COVERT on bundles of real-world Androidapps to determine its ability to detect inter-app vul-nerabilities for privilege escalation. Table 2 summa-rizes the statistical results obtained through runningCOVERT on Android app bundles. The total numberof components defined by the apps in each bundle isshown in the second column. Overall, Activities,Services, Broadcast receivers, and Contentproviders account for 73%, 11%, 12% and 2% ofcomponents, respectively.

The Intents column delineates the fraction of implic-it/explicit Intents out of total Intents in each bundle;on average, about 40% of Intents are implicit, showingthat developers, by and large, make inter-componentcommunications explicit. This is promising as there isno guarantee that the implicit Intent will be receivedby the intended recipient. The next column representsthe number of components’ interfaces described interms of Intent filters.

The Exposed column shows the number of compo-nent surfaces and permissions unsafely exposed toother applications. On average, COVERT detects 5 ex-posed components in each Bundle. Such componentshave defined Intent filters that make the components

accept incoming Intents, but do not properly enforceaccess permission, neither in the manifest file nor inthe source code. The last column then presents thetotal number of warnings generated by COVERT forapplications of each bundle, and each one representsa unique combination of source and destination com-ponents that can lead to a privilege escalation.

Note that reported warnings are about potentialsecurity issues. As with other techniques relying onstatic analysis, our approach is subject to false posi-tives, which could be due to two types of failures inmodel extraction:

• Strings are used extensively as identifiers in An-droid apps. Intent properties such as actions, datatypes, and permissions are all constructed fromstrings, as shown in our examples. Such stringscould also be altered by stateful operations, suchas the append method, which makes their accu-rate value elicitation quite challenging. In case anambiguous value is encountered, during the en-tity resolution step (Section 5.1), COVERT takes aconservative approach, and considers all possibleassignable values.

• COVERT performs reachability analysis (Sec-tion 5.3) to determine the permissions actuallyused by each component, thus ignoring permis-sions that are obtained, but not used. Yet, thereis a possibility that at run-time the permission-required API call or System Intent is not actuallyreached due to some conditional statements, forexample.

The conservative approach we take to deal withnon-determinism thus may introduce unnecessaryfalse positives. Encouragingly, this automated analysisstill results in a substantial reduction in subsequentmanual analysis. Specifically, less than 1% of applica-tion components (cf. Table 2, exposed components vs.total components) require further analysis by users.Also, the limitations of the static analysis with respectto, among other things, dynamically loaded codecould lead to false negatives as well. To facilitatethe process of manual analysis, COVERT provides thelocation of the potential vulnerability (i.e., filenameand method) within the source code.

The results also confirm that an approach combin-ing static analysis and model checking is effective incompositional analysis of Android apps. In this partic-ular case, the reported vulnerabilities provide crucialclues to the security analyst tasked with assessing thesecurity properties of a complex system. Such analysisis not possible with state-of-the-practice tools (e.g.,Fortify) that analyze the source code of an applicationin isolation.

In the next section, we interpret the results throughmanual analysis of a bundle of open-source applica-tions.




TABLE 2: Summary of experimental results obtained from running COVERT over App bundles.

Components Intents Intent Exposed TotalActivities Services Receivers Providers explicit implicit Filters Comps Perms Warnings

691 456Bundle 1 511 70 91 19 300 156 169 5 10 34

(%73.95) (%10.13) (%13.17) (%2.75) (%65.79) (%34.21)603 432

Bundle 2 434 76 78 15 302 130 148 7 2 16(%71.97) (%12.6) (%12.94) (%2.49) (%69.91) (%30.09)

592 312Bundle 3 425 65 85 17 218 94 185 4 3 25

(%71.79) (%10.98) (%14.36) (%2.87) (%69.87) (%30.13)582 366

Bundle 4 423 75 71 13 232 134 191 4 9 32(%72.68) (%12.89) (%12.2) (%2.23) (%63.39) (%36.61)

695 803Bundle 5 569 61 53 12 408 394 359 2 15 16

(81.88)% (8.78)% (7.63)% (1.73) % (50.81) % (49.07) %553 528

Bundle 6 445 52 47 9 278 249 225 2 10 15(80.48)% (9.41)% (8.5)% (1.63) % (52.66) % (47.16) %

352 577Bundle 7 242 43 62 5 349 227 137 4 16 35

(68.75)% (12.22)% (17.62)% (1.43) % (60.49) % (39.35) %682 1209

Bundle 8 556 57 62 7 728 480 175 3 5 22(81.53)% (8.36)% (9.1)% (1.03) % (60.22) % (39.71) %

511 622Bundle 9 358 71 75 7 251 370 231 5 7 22

(70.06)% (13.9)% (14.68)% (1.37) % (40.36) % (59.49) %660 527

Bundle 10 496 67 68 29 347 180 132 5 9 30(%75.15) (%10.15) (%10.3) (%4.39) (%65.84) (%34.16)

7.3 Manual AnalysisWe selected 50 applications from the F-Droid opensource repository, and then manually inspectedCOVERT’s warnings for these applications to evaluatehow many warnings correspond to real exploitablevulnerabilities. Statistics of the selected app set areprovided as Bundle 10 in the Table 2. More detailsabout the apps, including their name and modelcan be found on the project site3. In this section,we present the findings of our manual analysis anddiscuss three representative examples in detail.

COVERT generated 30 warnings for the 50 applica-tions. We manually reviewed all and categorized themaccording to the classification provided by Chin etal. [2], where each warning is classified as a vulnera-bility, not a vulnerability, or undetermined. We definea vulnerability to be a component lacking a particularpermission getting access to a functionality requiringthat permission through an interface exposed by avulnerable component. In order to detect vulnerabili-ties, we reviewed the application source code of bothsides (sender and destination) for each warning.

Among the 30 reported warnings, we discovered18 definite vulnerabilities. This represents a 60% truepositive rate, which is superior to the prior tech-nique [2], that aimed to identify inter-app vulnera-bilities by analyzing the source code of each app inisolation, with a true positive rate of 27.6%. More

3. http://www.sdalab.com/projects/covert

interestingly, of the 5 application components iden-tified as exposing permissions, all contain at least 1exploitable vulnerability.

In the rest of this section, we describe a few rep-resentative applications and the vulnerabilities wediscovered in them.

Case 1: Aard Dictionary → Podax.The first app is Aard Dictionary, a simple dic-

tionary and an offline Wikipedia reader. It defines aWebViewClient interface for handling incoming urls,and creates and sends an implicit Intent with the VIEWaction, should the scheme of the given url matcheswith one of the specified schemes, such as http, httpsand ftp.

On the other hand, the app bundle contains thePodax app, a podcast downloader and player appli-cation. This app accepts Intents with the VIEW action,and http scheme, which in turn can lead to messagepassing between the two apps. While the first app thatsends the Intent does not have the INTERNET permis-sion, the recipient app (Podax) has. In addition, thePodax app does not check whether the caller has theappropriate permission. This combination, thus, givesrise to a privilege escalation vulnerability.

The sender app here is benign, but if it was mali-cious it could use the other app’s unprotected capa-bility, which may lead to some security risks, such asphishing, by bringing up a web page and enticing theuser to enter payment or other private information.

Case 2: Binaural beats therapy → Ermete SMS.




Ermete SMS is a free web-based text messag-ing application that has WRITE_SMS permission.An Activity component of this application ex-poses an unprotected interface that receives Intentswith SEND action. Upon receiving an Intent, theComposeActivity component extracts the payloadof the given Intent, and sends that data via text mes-sage to a number specified in the payload, withoutchecking the permission of Intent sender.

The other app, Binaural beats therapy, is de-signed for relaxation, creativity and many other de-sirable mental states. This app does not have theWRITE_SMS permission, but it sends an Intent withSEND action and text/plain payload data, which couldbe received by the first app. This case represents afalse positive as the Intent sent by the Binauralbeats therapy app does not actually contain thefields required by Ermete SMS to send a text mes-sage, but points to an important security risk, wherea malicious app could use the exposed messagingservice.

Case 3: PurpleDock → RMaps.RMaps is an on- and off-line navigation

tool. In addition to GPS permissions likeACCESS_FINE_LOCATION, it has INTERNETpermissions to work with online maps such asGoogle and Microsoft maps. This application exposesan activity, which receives VIEW Intents with geoscheme, a URI scheme for geographic locations. Onthe other hand, PurpleDock is a simple app thatautomatically turns on when the handset is placedinto the car mount, and provides navigation as oneof its features.RMaps’s geo Intents are intended for internal use,

and other applications, including PurpleDock thatsends a geo message via Intent, should not be able tocontrol locations shown by the app interface. How-ever, with the current implementation, as it doesnot check the permission of Intent senders, the ex-posed component can be manipulated by a maliciousapplication for GPS spoofing (i.e., display a wronglocation).

7.4 Compositional vs. Single App Analysis

Enck et al. [6] provide a set of practical securityrules, called Kirin rules, to prevent malwares fromexploiting Android applications. Each rule representsundesirable security properties in terms of the config-uration available in manifest files. Kirin rules, thus,decide whether the security configuration bundledwith a single app is safe or not, but they do notconsider the case in which malicious apps collude tocombine their permissions, allowing them to performactions beyond their individual privileges.

To analyze these rules using our approach, weformalized them in Alloy. Each rule is modeled asan assertion to be analyzed independently. We also

developed a compositional version of each rule, lever-aging the privilege escalation predicate. This in turnenabled us to apply the two sets of rules and comparethe results of isolated analysis versus compositionalanalysis.

To make the idea concrete, we illustrate one of theserules along with its formal representations for bothcompositional and single app analysis. Consider thefollowing Kirin security rule (KSR 6): “An applicationmust not have RECEIVE_SMS and WRITE_SMS permis-sion labels [6].”

Listing 10 partially outlines the two Alloy assertionsspecified to check the rule against either (a) a singleapp or (b) a combination of apps that may collude tocombine their permissions. Assertion (a) states a directrepresentation of the aforementioned rule in Alloy,while assertion (b) restates the same rule againstmultiple apps. It uses the isPrivilegeEscalationpredicate (line 16) to check the occurrence of privilegeescalation between the two apps with respect to thep2 permission. The p1 and p2 permissions couldbe either RECEIVE_SMS or WRITE_SMS (lines 11–12), but they should be distinct as enforced by disjkeyword (line 11). The predicate takes as input twocomponents c1 and c2, an Intent, and a permission.The c1 component belongs to the app1 and c2 tothe app2, omitted in Listing 10 (b) in the interestof space. The assertion then at the very end of line16 checks the case in which one app contains bothpermission labels. Note that in practice developingtwo different assertions is not necessary as the latter,in effect, covers the former. Here, we developed theformer for experimental purposes, and to compare theresults of single versus compositional analysis.

We analyzed all the apps in the Malgenome repos-itory against each of these rules. Table 3 summarizesthe results. Rows represent Kirin security rules that

1 // ( a ) s i n g l e app a n a l y s i s2 a s s e r t Kir inRule6{3 no p1 , p2 : Permission | {some app : Appl icat ion |4 ( p1 = RECEIVE SMS) and ( p2 = WRITE SMS) and5 ( p1 in app . usesPermissions ) and ( p2 in app .

usesPermissions )6 }7 }8 −−−−−−−−−−−−−−−−−−−−−−−−−−−−9 // ( b ) composi t ional app a n a l y s i s

10 a s s e r t KirinRule6 Compos{11 no d i s j p1 , p2 : Permission | {some app1 , app2 :

Applicat ion ,12 c1 , c2 : Component , i n t e n t 1 : I n t e n t |13 ( p1 in RECEIVE SMS+WRITE SMS) and14 ( p2 in RECEIVE SMS+WRITE SMS) and15 ( p1 in app1 . usesPermissions ) and ( p2 in app2 .

usesPermissions )16 and ( i s P r i v i l e g e E s c a l a t i o n [ c1 , c2 , in tent1 , p2 ] or (

app1 = app2 ) )17 }18 }

Listing 10: Specification of a Kirin rule for (a) singleand (b) compositional app analysis.




TABLE 3: Compositional vs. Single App Analysis ofKirin Rules over the Malgenome app repository.

Sec. Sing. App. CompositionalRule Analysis AnalysisKSR 1 - -KSR 2 - -KSR 3 2 2KSR 4 2 8KSR 5 2 11KSR 6 10 14KSR 7 11 14KSR 8 3 3Overall 30 52

we formally modeled in Alloy to be analyzed usingour approach. Columns represent the analysis type,either single app analysis (as performed by the Kirintool [6]) or compositional analysis. Each cell indicatesthe number of vulnerabilities detected. As we can see,the compositional rule analysis detects more vulner-abilities, without missing any vulnerability identifiedby single app analysis. The experimental results indi-cate the overall improvement of 73% in detecting vul-nerabilities using a compositional analysis approach.

7.5 Performance and TimingThe final evaluation criteria are the performancebenchmarks of model extraction and formal analysisactivities. We used a PC with an Intel Core i7 2.4GHz CPU processor and 8 GB of main memory,and leveraged Sat4J as the SAT solver during theexperiments.

Compositional Analysis of Android apps using ourapproach consists of three steps: (1) The app modelsare collected and documented as Alloy specifications.(2) The extracted Alloy models are transformed into 3-SAT clauses using the Alloy Analyzer. (3) An off-the-shelf SAT solver explores the space to find counterex-amples. We measured the computation time requiredfor each step separately.

The scatter diagram shown in Figure 5 plots thetime taken to analyze the collected apps for model ex-traction in seconds. The results show that the analysis

Fig. 5: Scatter plot representing analysis time formodel extraction of Android apps.

TABLE 4: Experiments performance statistics.

Construction AnalysisTime (Sec) Time (Sec)

Bundle 1 412 252Bundle 2 226 123Bundle 3 441 65Bundle 4 158 57Bundle 5 191 239Bundle 6 88 85Bundle 7 120 123Bundle 8 350 374Bundle 9 295 299

Bundle 10 204 45

time scales almost linearly with the size of apps in allthree repositories. However, as the set of most popularapps collected from the Google Play repository—represented by dark blue in the diagram—are typi-cally larger than apps from the other two repositories,their model extraction takes more time. Accordingto the diagram, our approach is able to staticallyanalyze and infer specifications for the largest appsin less than three minutes. As our implementationseparates model extraction analysis from Alloy modelgeneration, and each app bytecode is analyzed inde-pendently (cf. Section 5), the total static analysis timescales linearly with the total size of apps.

Table 4 shows the time involved in compositionalverification of Android apps (steps 2 and 3). The firstcolumn represents the time spent on transformingAlloy models into 3-SAT clauses, and the second thetime spent in SAT solving to find all counterexamplesfor each app bundle. The timing results show thatCOVERT is able to analyze bundles of apps containinghundreds of components in the order of a few minutes(on an ordinary laptop), confirming that the proposedtechnology based on a lightweight formal analyzer isfeasible.

8 DISCUSSION AND LIMITATIONS

There is a growing need for technologies that cansupport the security analysis of complex systems ina compositional manner, whereby the security of asystem is reasoned about in terms of the securityproperties inferred from its constituents. We argue thisis the holy grail of software security analysis research.For the security analysis techniques to scale to ever-increasing complex systems, they need to becomecompositional in nature. COVERT takes an importantstep towards this overarching objective in the contextof Android apps, but we envision the ideas set forthin this research to find a broader application in othercomputing domains as well.

Note that single app analysis and compositionalanalysis have their own technical merits. From anapplication developer’s perspective, analyzing eachapp in isolation may provide sufficient feedback to fixthe issues in the code (i.e., remove the vulnerabilities).




1 a s s e r t appCollusion{2 no d i s j cmp1 , cmp2 : Component |3 some cmp1 . paths && some cmp2 . paths &&4 cmp1 . app != cmp2 . app &&5 match [ cmp1 . paths . d e s t i n a t i o n , cmp2 . paths . entry ]6 }78 pred match ( pathSink : s e t Resource+Intent ,9 pathSource : s e t Resource+ I n t e n t F i l t e r ){

10 SDCARD in pathSource & pathSink | |11 LOG in pathSource & pathSink | |12 ( some i : In tent , f : I n t e n t F i l t e r |13 i in pathSink && f in pathSource && matchIPC [ i , f ] )14 }

Listing 11: Specification of the application collusionvulnerability in Alloy.

On the other hand, when the purpose of analysis is toassess the trustworthiness of a system, comprised ofmultiple proprietary apps that may interact with oneanother, compositional analysis is needed to detectvulnerabilities that may exist in the system. One canimagine an organization may need to use a tool suchas COVERT to analyze the security properties of appsdeployed on phones assigned to its employees. Suchan organization may not be in a position to fix theissues in the apps, as the apps may be proprietary,but it can control the apps that are installed on thedevices.

Our analysis indicates that IPC vulnerabilities areubiquitous, and demonstrates why prior techniquesrelying only on single app analysis are insufficient fordetecting such vulnerabilities. Our experiences with anovel approach for compositional app analysis and itsevaluation in the context of hundreds of real-worldAndroid apps collected from variety of repositorieshave been very positive. The experimental data showsthat COVERT can effectively detect such inter-appvulnerabilities in the order of few minutes.

8.1 Development Effort

The framework specification is not expected to bewritten by individual users of COVERT, rather by theprovider of the framework or COVERT. The specifica-tion for a framework, such as Android, is developedonce and can be reused by others. Thus, it poses aone-time cost, and the required effort depends onthe level of familiarity with the framework and thespecification language. Using executable specificationlanguages, one can also immediately check the cor-rectness of even partial specifications. In our ownexperience, Alloy helped us to find errors early inspecifying formal semantics. More specifically, duringthe modeling process, its analyzer performed syn-tactic checks to expose, for instance, inaccurate useof signatures (such as accessing a nonexistent fieldof a signature). We also used the analyzer to checkthe conformance of automatically generated modelsof apps derived through static analyzer to the frame-work meta-model.

8.2 Other Types of VulnerabilitiesWhile privilege escalation vulnerability has been thefocus of our research, we believe COVERT can beextended, and significant components of it reused,for detecting other types of inter-app vulnerabilities.For instance, an important class of inter-app vulner-abilities are due to information leakage. For thesetypes of vulnerabilities, COVERT’s program analysisneeds to be extended to take information flow intoaccount for Android apps. While not the focus of thispaper, in an alternative configuration, we augmentedCOVERT’s reachability analysis described in Section5.3 with a taint flow analysis approach (see [28]) todetect possible information leaks between apps.

We illustrate the reuse and extension potential ofCOVERT through an example of the application col-lusion vulnerability. Consider two applications A andB; B reads data from a particular folder in SD cardand sends the data out through Internet, and A writesdata to the folder that B reads from. Since B does notexpose the sending action through its interface (Intent-Filter), it cannot be detected by the privilegeEscalationcheck, specified in Listing 8.

To extend COVERT for supporting the analysis ofthis scenario, the only thing required is to model itas an assertion, expressing properties to be checkedin the extracted specifications. Listing 11 expressessuch an assertion for the application collusion. Theassertion states that there are two components indifferent applications; each contains a sensitive dataflow path, where the sink of one matches the sourceof the other. Recall from Section 6 that the pathsfield denotes information paths between permissiondomains for each component.

Continuing with our example, the apps A and Bcontain the flow permissions: IMEI → SDCARD andSDCARD → NETWORK, respectively. These two pathswill set the match predicate to be true (line 8), and thusCOVERT identifies it as an instance of the applicationcollusion. Note that since applications specificationsand properties to be checked are strictly separated,arbitrary vulnerabilities can be detected with minimaleffort.

8.3 LimitationsThere are of course limitations in our approach. Sim-ilar to any approach based on static analysis, ourapproach is subject to false positives. We believe afruitful avenue of future research is to complementCOVERT with dynamic analysis techniques. In princi-ple, it should be possible to leverage dynamic analysistechniques to automatically confirm some of the vul-nerabilities (e.g., by executing the vulnerable code),further reducing and targeting the manual analysiseffort.

Another advantage of dynamic analysis is that itcan be used to address vulnerabilities in native code.




Android Apps may include native code in addition toJava code, in the form of a Java Native Interface (JNI)library. Although native code is also obligated to thepermission system [5], it may dynamically load code,which cannot be sufficiently addressed through staticanalysis techniques.

Through dynamic analysis it would also be pos-sible to address upcoming features, such as GoogleApp Ops, which provides a Permission Manager thatallows users to revoke granted permissions after in-stallation time. This feature was introduced in An-droid 4.3, but subsequently removed in Android 4.4.2[29]. Given that granular revocation or allowance ofpermissions after installation time is a dynamic mech-anism, a dynamic analysis would be needed to handlepossible vulnerabilities arising from this feature. Forexample, COVERT’s incremental, compositional anal-ysis for permission leakages can be performed on apermission-modified app and related apps at runtime,with appropriate instrumentation or monitoring capa-bilities added.

In addition to Intent-based event messaging as onetype of IPC mechanism, Android applications cancommunicate through remote procedure calls (RPC)by method-invocation interaction using stubs, whichare automatically generated from the specification of acomponent’s interfaces in Android’s Interface Defini-tion Language (AIDL). While the focus of this paperis on the inter-app vulnerabilities that arise due toIntent-based event messaging—shown to be the pri-mary IPC mechanism in Android—supporting otherIPC mechanisms constitutes an interesting avenue forour future work.

This paper provides substantial supporting evi-dence for analyzing one of the most significant inter-app vulnerabilities, i.e. privilege escalation. It wouldbe interesting to see how our approach fares whenapplied to other types of inter-app vulnerabilities [2],[8], [30], which forms a thrust of our future work.

9 RELATED WORK

Android security has received a lot of attention inrecently published literature, due mainly to the pop-ularity of Android as a platform of choice for mobiledevices, as well as increasing reports of its vulnera-bilities [1], [30]. Here, we provide a discussion of therelated efforts in light of our research.

9.1 Android Program Analysis for Security

A large body of work [2], [3], [31]–[35] focuses on per-forming program analysis over Android applicationsfor security, which can be categorized based on theirunderlying static or dynamic analysis technique.

Chin et al. [2] studied security challenges of An-droid communication, and developed ComDroid todetect those vulnerabilities through static analysis of

each app. Octeau et al. [33] developed Epicc for analy-sis of Intent properties—except data scheme—throughinter-procedural data flow analysis. FlowDroid [28]introduces a precise approach for static taint flowanalysis in the context of each application component.CHEX [36] also takes a static method to detect com-ponent hijacking vulnerabilities within an app. Weshare with this approach the emphasis on separatingmodel extraction from vulnerability analysis, enablingextension/revision of each, independent of the other.However, these research efforts, like many others westudied, are mainly focused on Intent and componentanalysis of one application. COVERT’s analysis, how-ever, goes far beyond single application analysis, andenables compositional analysis of the overall securityposture of a system, greatly increasing the scope ofvulnerability analysis. Doing this requires applicationof verification techniques in a way scalable to han-dle analysis of complex systems comprising multipleapps interacting with each other. COVERT, to ourknowledge, is the first tool with this capability.

DidFail [37] introduces an approach for trackingdata flows between Android components to detectpotential data leaks. However, it does not target theproblem we are addressing, namely detecting thepermission leakage. Moreover, similar to many othertechniques we studied, DidFail is a purely programanalysis tool, and does not incorporate a formal veri-fication technique.

Along the same line, AndroidLeak [31] staticallyanalyzes information leak in Android. Its analysisdoes not cover Intents, nor cross-application flows.SCanDroid [38] statically analyzes data flows to detectpermission inconsistencies between applications thatcould possibly allow malicious access to sensitiveinformation. It requires the source code of applica-tions, and has never been evaluated over real-worldapplications. Mann and Starostin [34] also developeda framework to detect privacy leaks from the An-droid APIs. Similar to ScanDroid, this framework wasnever tested against real-world applications. Zhouand Jiang [35] analyzed vulnerabilities that are due tothe existence of unprotected content provider compo-nents. While this work is concerned with the potentialrisks of passively leaking content, it does not considerthe problem that we address, the automation of inter-app vulnerability analysis.

Apart from techniques based on static analysis, sev-eral tools use dynamic analysis to detect vulnerabili-ties in smartphone applications. TaintDroid [3] detectsinformation leak vulnerabilities using dynamic taintflow analysis at the system level. IPC Inspection [39]prevents privilege escalation at OS level. Recipientsof IPC requests are re-instantiated according to theprivileges of their callers, guaranteeing that the calleedoes not have privileges more than that of the caller.However, maintaining multiple instances of applica-tions with modified privileges imposes a notable per-




formance overhead. Saint [40] analyzes configurationand runtime behavior of Android apps to enforce se-curity policy and to allow only legitimate permissions.

These research efforts share our emphasis on lever-aging program analysis to capture some informa-tion from application implementations. However, ourwork differs in several ways. First, our approach isgeared towards the application of formal techniquesto verify certain properties in Android applications. Anovel contribution of our work is the ability to bridgefrom application implementations to formal specifi-cations using static code analysis techniques. Second,previous studies of Android applications analyze asingle app in isolation. Our modular approach canbe used to greatly increase the scope of applicationanalysis by inferring the security properties fromindividual apps and checking them as a whole forvulnerabilities that are due to the interaction of appscomprising a system. Third, many of the previouslyproposed solutions [3], [6], [9], [39] require changes toone or more components of the Android middleware,such as Application Installer, Reference Monitor, andDalvik Virtual Machine. Our approach, in contrast,requires no platform modifications.

9.2 Android PermissionsThe other relevant line of research focuses on An-droid’s permissions and their use across applica-tions [6], [21], [41]–[45]. Barrera et al. [41] exam-ined permission requirements over a set of 1,100Android applications to analyze how permissions areused in such applications. Their result shows that asmall fraction of permissions are extensively used.Kirin [6] extends the application installer componentof Android’s middleware to check the permissionsrequested by applications against a set of securityrules. These predefined rules are aimed to preventunsafe combination of permissions that may leadto insecure data flows. Whyper [45] is a tool thatchecks the app’s requested permissions against itsdescription, thereby enabling the user to determine ifcertain requested permissions are suspicious. Vidas etal. [44] have developed a tool that scans the Androiddocumentation to extract permission specifications.These techniques typically rely only either on the An-droid documentation or permission requests specifiedwithin the application manifest, rather than analyzingthe code to check whether or how such permissionsare used by applications.

Along the same line, another thrust of researchstatically analyzes the apps source code to studytheir permission use. Among others, Felt et al. [5]have developed Stowaway, a tool for performing anover-privilege analysis on application source code.Applying automated testing techniques on the An-droid API, they developed a set of permission maps—documenting which APIs require what permissions—used in detecting overprivilege. Similarly, Au et

al. [18] have developed PScout to extract the permis-sion specification from the Android OS source codeusing static analysis, which led to a comprehensiveset of permission maps for Android. We used PSCout’spermission map in our tool implementation to analyzewhether applications under consideration properlycheck permissions before calling APIs, thereby reduc-ing false positives in COVERT.

9.3 Formal ApproachesThe other relevant thrust of research has focusedon formal modeling and automated verification ofsoftware applications. Fragkaki et al. [7] proposed aformal framework as an extension to the Androidpermission mechanism. Chaudhuri [46] also proposeda formal language to describe applications and atype system to reason about information flows. Thiswork, however, does not provide any implementationfor the proposed approach. Martin et al. [47] devel-oped PQL, which provides a specification languagefor querying Java applications to detect errors andsecurity flaws. PQL does not include mechanismsfor handling Intents, which require a flow-sensitiveanalysis; the Android lifecycle; and bundles of ap-plications. Thus, PQL focuses on single applications,while COVERT focuses on compositional analysis.Alloy also has been widely used for modeling andanalysis in a variety of contexts, including checkingcode against partial specifications [48]–[50], analysisof software architecture [51], [52], specification basedtesting [53], and security [54]–[56]. In our prior work,we developed DroidGuard [55], which uses the Alloyanalysis engine to generate specifications of Androidsecurity policies. These policies are then proactivelyapplied as preventive measures to guard against yetunknown malicious behavior. While DroidGuard tar-gets synthesis and runtime enforcement of securitypolicies, this work addresses precise detection of inter-app vulnerabilities. Chen et al. [56] provided a logicalformulation of general security concepts, and mod-eled it in Alloy. Their model is very abstract, andhas not been applied in any particular domain orapplication. Targeting a real-world banking system,Ramananandro [54] used Alloy to model and checkspecifications of an electronic smart card system.However, unlike our work, the translation to Alloyis not automated in this research effort. To the best ofour knowledge, COVERT is the first formally-preciseanalysis technique leveraging Alloy for automatedcompositional verification of Android apps.

10 CONCLUSION

This paper presents a novel approach for composi-tional analysis of Android inter-app vulnerabilities.Our approach employs static analysis to automati-cally recover models that reflect Android apps andinteractions among them. It is able to leverage these




models to identify vulnerabilities due to interaction ofmultiple apps that cannot be detected with prior tech-niques relying on a single app analysis. We formalizedthe basic elements of our analysis in an analyzablespecification language based on relational logic, anddeveloped a prototype implementation, COVERT, ontop of our formal analysis framework. The experi-mental results of evaluating COVERT against privi-lege escalation—one of the most prominent inter-appvulnerabilities—in the context of hundreds of real-world Android apps corroborates its ability to findvulnerabilities in bundles of some of the most popularapps on the market.

11 ACKNOWLEDGMENT

This work was supported in part by awardsD11AP00282 from the US Defense Advanced ResearchProjects Agency, H98230-14-C-0140 from the US Na-tional Security Agency, HSHQDC-14-C-B0040 fromthe US Department of Homeland Security, and CCF-1252644 from the US National Science Foundation.

REFERENCES[1] A. Shabtai, Y. Fledel, U. Kanonov, Y. Elovici, S. Dolev,

C. Glezer, Google android: A comprehensive security assess-ment, Security & Privacy, IEEE 8 (2) (2010) 35–44.

[2] E. Chin, A. P. Felt, K. Greenwood, D. Wagner, Analyzing inter-application communication in android, in: Proceedings of the9th international conference on Mobile systems, applications,and services, MobiSys ’11, ACM, New York, NY, USA, 2011,pp. 239–252. doi:10.1145/1999995.2000018.

[3] W. Enck, P. Gilbert, B. g. Chun, L. P. Cox, J. Jung, P. McDaniel,A. N. Sheth, Taintdroid: An information-flow tracking systemfor realtime privacy monitoring on smartphones, in: Proc. ofUSENIX OSDI, 2011.

[4] P. Hornyack, S. Han, J. Jung, S. Schechter, D. Wetherall,These aren’t the droids you’re looking for: Retrofitting androidto protect data from imperious applications, in: Proceedingsof the ACM Conference on Computer and CommunicationsSecurity (CCS), 2011, pp. 639–652.

[5] A. P. Felt, E. Chin, S. Hanna, D. Song, D. Wagner, Androidpermissions demystified, in: Proceedings of the ACM Confer-ence on Computer and Communications Security (CCS), 2011,pp. 627–638.

[6] W. Enck, M. Ongtang, P. McDaniel, On lightweight mo-bile phone application certification, in: Proceedings of theACM Conference on Computer and Communications Security(CCS), 2009.

[7] E. Fragkaki, L. Bauer, L. Jia, D. Swasey, Modeling andenhancing android’s permission system, in: Proc. of ESORICS,2012.URL http://link.springer.com/chapter/10.1007/978-3-642-33167-1 1

[8] S. Bugiel, L. David, Dmitrienko, T. A. Fischer, A. Sadeghi,B. Shastry, Towards taming privilege-escalation attacks onandroid, in: Proc. of NDSS, 2012.

[9] M. Dietz, S. Shekhar, Y. Pisetsky, A. Shu, D. S. Wallach, Quire:Lightweight provenance for smart phone operating systems,in: Proc. of USENIX, 2011.

[10] D. Jackson, Alloy: a lightweight object modelling notation,TOSEM 11 (2) (2002) 256–290.URL http://portal.acm.org/citation.cfm?doid=505145.505149

[11] R. Valle e-Rai, P. Co, E. Gagnon, L. Hendren, V. Lam,P.and Sundaresan, Soot - a java bytecode optimization frame-work, in: Proc. of CASCON’99, 1999.

[12] A. Bartel, J. Klein, Y. LeTraon, M. Monperrus, Dex-pler:converting android dalvik bytecode to jimple for staticanalysis with soot, in: Proc. of SOAP, 2012.

[13] J. Woodcock, P. G. Larsen, J. Bicarregui, J. Fitzgerald, Formalmethods: Practice and experience, ACM Comput. Surv. 41 (4)(2009) 19:1–19:36. doi:10.1145/1592434.1592436.URL http://doi.acm.org/10.1145/1592434.1592436

[14] P. Zave, A practical comparison of alloy and spin, Tech. rep.(2012).

[15] Android api reference document,http://developer.android.com/reference.

[16] A. V. Aho, M. S. Lam, R. Sethi, J. D. Ullman, Compilers:Principles, Techniques, and Tools (2Nd Edition), Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2006.

[17] Android developers guide.URL http://developer.android.com/guide/topics/fundamentals.html

[18] K. W. Y. Au, Y. F. Zhou, Z. Huang, D. Lie, Pscout: Analyzingthe android permission specification, in: Proceedings of theACM Conference on Computer and Communications Security(CCS), 2012.

[19] O. Tripp, M. Pistoia, P. Cousot, R. Cousot, S. Guarnieri, An-dromeda: Accurate and scalable security analysis of web appli-cations, in: Fundamental Approaches to Software Engineering,Springer, 2013, pp. 210–225.

[20] E. Torlak, A constraint solver for software engineering: Find-ing models and cores of large relational specifications, PhDthesis, MIT (Feb. 2009).URL http://alloy.mit.edu/kodkod/

[21] S. Holavanalli, D. Manuel, V. Nanjundaswamy, B. Rosenberg,F. Shen, S. Y. Ko, L. Ziarek, Flow permissions for android, in:Proceeding of the 28th IEEE/ACM International Conferenceon Automated Software Engineering (ASE), 2013.

[22] L. Davi, A. Dmitrienko, A.-R. Sadeghi, M. Winandy, Privilegeescalation attacks on android, in: Proceedings of the 13thinternational conference on Information security (ISC), 2010.

[23] Google play market.URL http://play.google.com/store/apps/.

[24] F-droid.URL https://f-droid.org/.

[25] Bazaar.URL https://cafebazaar.ir//.

[26] Malgenome project, http://www.malgenomeproject.org.[27] Freemarker java template engine, http://freemarker.org/.[28] S. Arzt, S. Rasthofer, E. Bodden, A. Bartel, J. Klein, Y. Le

Traon, D. Octeau, P. McDaniel, Flowdroid: Precise context,flow, field, object-sensitive and lifecycle-aware taint analysisfor android apps, in: Proceedings of the 35th annual ACMSIGPLAN conference on Programming Language Design andImplementation (PLDI 2014), 2014.

[29] Protecting your privacy: App ops, privacy guard, andxprivacy.URL http://www.xda-developers.com/protecting-your-privacy-app-ops-privacy-guard-and-xprivacy/

[30] W. Enck, D. Octeau, P. McDaniel, S. Chaudhuri, A study ofandroid application security, in: Proc. of USENIX, 2011.

[31] C. Gibler, J. Crussell, J. Erickson, H. Chen, Androidleaks:Automatically detecting potential privacy leaks in androidapplications on a large scale, in: Trust and Trustworthy Com-puting, Springer, 2012, pp. 291–307.

[32] M. Grace, Y. Zhou, Z. Wang, X. Jiang, Systematic detection ofcapability leaks in stock android smartphones, in: Proceedingsof the 19th Annual Symposium on Network and DistributedSystem Security, 2012.

[33] D. Octeau, P. McDaniel, S. Jha, A. Bartel, E. Bodden, J. Klein,Y. L. Traon, Effective Inter-Component Communication Map-ping in Android with Epicc: An Essential Step Towards Holis-tic Security Analysis, in: Proceedings of the 22nd USENIXSecurity Symposium, Washington, DC, 2013.URL http://siis.cse.psu.edu/epicc/papers/octeau-sec13.pdf

[34] C. Mann, A. Starostin, A framework for static detection of pri-vacy leaks in android applications, in: Proceedings of the 27thAnnual ACM Symposium on Applied Computing, SAC’12,ACM, New York, NY, USA, 2012, pp. 1457–1462.

[35] Y. Zhou, X. Jiang, Detecting passive content leaks and pol-lution in android applications, in: Proceedings of the 20thNetwork and Distributed System Security Symposium (NDSS2013), 2013.

http://dx.doi.org/10.1145/1999995.2000018

http://link.springer.com/chapter/10.1007/978-3-642-33167-1_1




http://portal.acm.org/citation.cfm?doid=505145.505149

http://portal.acm.org/citation.cfm?doid=505145.505149

http://doi.acm.org/10.1145/1592434.1592436

http://doi.acm.org/10.1145/1592434.1592436

http://dx.doi.org/10.1145/1592434.1592436

http://doi.acm.org/10.1145/1592434.1592436

http://developer.android.com/guide/topics/fundamentals.html



http://alloy.mit.edu/kodkod/



http://play.google.com/store/apps/.

http://play.google.com/store/apps/.

https://f-droid.org/.

https://f-droid.org/.

https://cafebazaar.ir//.

https://cafebazaar.ir//.

http://www.xda-developers.com/protecting-your-privacy-app-ops-privacy-guard-and-xprivacy/




http://siis.cse.psu.edu/epicc/papers/octeau-sec13.pdf







[36] L. LU, Z. LI, Z. WU, W. LEE, G. JIANG, Chex: staticallyvetting android apps for component hijacking vulnerabilities,in: Proceedings of the ACM Conference on Computer andCommunications Security (CCS), 2012.

[37] W. Klieber, L. Flynn, A. Bhosale, L. Jia, L. Bauer, Android taintflow analysis for app sets, in: Proceedings of the 3rd ACMSIGPLAN International Workshop on the State of the Art inJava Program Analysis, SOAP ’14, ACM, New York, NY, USA,2014, pp. 1–6. doi:10.1145/2614628.2614633.URL http://doi.acm.org/10.1145/2614628.2614633

[38] A. P. Fuchs, A. Chaudhuri, J. S. Foster, Scandroid: Automatedsecurity certification of android applications (2009).

[39] A. P. Felt, H. Wang, A. Moshchuk, S. Hanna, E. Chin, Permis-sion re-delegation: Attacks and defenses, in: Proc. of the 20thUSENIX Security Symposium, 2011.

[40] M. Ongtang, S. McLaughlin, W. Enck, P. McDaniel, Semanti-cally rich application-centric security in android, in: Proc. ofthe 25th Annual Computer Security Applications Conference(ACSAC), 2009.

[41] D. Barrera, H. Kayacik, P. Oorschot, A. Somayaji, A methodol-ogy for empirical analysis of permission-based security mod-els and its application to android, in: Proceedings of theACM Conference on Computer and Communications Security(CCS), 2010.

[42] Y. Zhou, Z. Y. Wang, W. Zhou, X. Jiang, Hey, you, get off ofmy market: Detecting malicious apps in official and alternativeandroid markets, in: Proceedings of the 19th Network andDistributed System Security Symposium (NDSS 2012), 2012.

[43] M. Grace, Y. Zhou, Q. Zhang, S. Zou, X. Jiang, Riskranker:scalable and accurate zero-day android malware detection,in: Proceedings of the International Conference on MobileSystems, Applications, and Services (MobiSys 2012), 2012.

[44] T. Vidas, N. Christin, L. Cranor, Curbing android permissioncreep, in: Proceedings of the Web 2.0 Security and Privacy 2011workshop (W2SP 2011), 2011.

[45] R. Pandita, X. Xiao, W. Yang, W. Enck, T. Xie, Whyper:Towards automating risk assessment of mobile applications,in: Proceedings of the 22Nd USENIX Conference on Security,SEC’13, USENIX Association, Berkeley, CA, USA, 2013, pp.527–542.URL http://dl.acm.org/citation.cfm?id=2534766.2534812

[46] A. Chaudhuri, Language-based security on android, in: Pro-ceedings of Programming Languages and Analysis for Secu-rity (PLAS’09), 2009, pp. 1–7.

[47] M. Martin, B. Livshits, M. S. Lam, Finding application errorsand security flaws using pql: a program query language, in:ACM SIGPLAN Notices, Vol. 40, ACM, 2005, pp. 365–383.

[48] S. Khurshid, Darko Marinov, D. Jackson, An analyzable anno-tation language, in: Proceedings of the 17th ACM SIGPLANconference on Object-oriented programming, systems, lan-guages, and applications, OOPSLA ’02, ACM, New York, NY,USA, 2002, pp. 231–245. doi:10.1145/582419.582441.URL http://doi.acm.org/10.1145/582419.582441

[49] D. Jackson, M. Vaziri, Finding bugs with a constraint solver,in: Proceedings of the International Symposium on SoftwareTesting and Analysis (ISSTA), 2000.

[50] J. P. Near, A. Milicevic, E. Kang, D. Jackson, A lightweight codeanalysis and its role in evaluation of a dependability case, in:Proceedings of the 33rd International Conference on SoftwareEngineering, ICSE’11, ACM, New York, NY, USA, 2011, pp.31–40. doi:10.1145/1985793.1985799.URL http://doi.acm.org/10.1145/1985793.1985799

[51] J. S. Kim, D. Garlan, Analyzing architectural styles, Journal ofSystems and Software 83 (7) (2010) 1216–1235.

[52] H. Bagheri, K. Sullivan, Monarch: Model-based develop-ment of software architectures, in: Proceedings of the 13thACM/IEEE International Conference on Model Driven Engi-neering Languages and Systems (MODELS), 2010, pp. 376–390.

[53] S. A. Khalek, B. Elkarablieh, Y. O. Laleye, S. Khurshid, Query-aware test generation using a relational constraint solver, in:Proceedings of the 23rd IEEE/ACM International Conferenceon AutomatedSoftwareEngineering, pp. 238–247.

[54] T. Ramananandro, Mondex, an electronic purse: Specificationand refinement checks with the alloy model-finding method,Formal Asp. Comput. 20 (1) (2008) 21–39.

[55] H. Bagheri, A. Sadeghi, R. Jabbarvand, S. Malek, Auto-mated dynamic enforcement of synthesized security policiesin android, Tech. Rep. GMU-CS-TR-2015-5, Department ofComputer Science, George Mason University, 4400 UniversityDrive MSN 4A5, Fairfax, VA 22030-4444 USA (2015).

[56] C. Chen, P. Grisham, S. Khurshid, D. Perry, Design andvalidation of a general security model with the alloy analyzer,in: Proceedings of the ACM SIGSOFT First Alloy Workshop,pp. 38–47.

Hamid Bagheri is a Postdoctoralresearcher at the department ofComputer Science at George Ma-son University and the ComputerScience and Artificial IntelligenceLaboratory at MIT. He received hisPh.D. in Computer Science fromUniversity of Virginia, a M.Sc. inSoftware Engineering from SharifUniversity of Technology, and hisB.Sc. in Computer Engineeringfrom University of Tehran. Hamid

is broadly interested in software engineering, andparticularly in practical software synthesis and analy-sis using concepts from fields like formal methods,program analysis, model-driven development, andsoftware architecture. He is a member of the ACMand IEEE.

Alireza Sadeghi is a Ph.D.student in the Computer ScienceDepartment at George MasonUniversity. His research interestsfocus on software engineering,specifically, application ofprogram analysis in security andenergy consumption assessmentof mobile applications. Sadeghireceived the B.S. degree incomputer (software) engineeringand M.S. degree in information

technology from Sharif University of Technology in2008 and 2010, respectively. He is a member of ACM,and ACM SIGSOFT.

Joshua Garcia is a PostdoctoralResearch Fellow in the ComputerScience Department at GeorgeMason Universiy (GMU). Hereceived his Ph.D. and M.S.degrees in Computer Sciencefrom the University of SouthernCalifornia (USC), and his B.S.degree in Computer Engineeringand Computer Science from USC.Garcia’s research interests are insoftware engineering. His workfocuses on software architecture,

software maintenance and re-engineering, andsoftware security.

http://doi.acm.org/10.1145/2614628.2614633

http://doi.acm.org/10.1145/2614628.2614633

http://dx.doi.org/10.1145/2614628.2614633

http://doi.acm.org/10.1145/2614628.2614633

http://dl.acm.org/citation.cfm?id=2534766.2534812



http://doi.acm.org/10.1145/582419.582441

http://doi.acm.org/10.1145/582419.582441

http://dx.doi.org/10.1145/582419.582441

http://doi.acm.org/10.1145/582419.582441

http://doi.acm.org/10.1145/1985793.1985799

http://doi.acm.org/10.1145/1985793.1985799

http://dx.doi.org/10.1145/1985793.1985799

http://doi.acm.org/10.1145/1985793.1985799




Sam Malek is an Associate Profes-sor in the Computer Science De-partment at George Mason Uni-versity (GMU). He is also the di-rector of GMU’s Software Designand Analysis Laboratory. His gen-eral research interests are in thefield of software engineering, andto date his focus has spanned theareas of software architecture, au-tonomic computing, software se-

curity, and software analysis and testing. Malek re-ceived his Ph.D. and M.S. degrees in Computer Sci-ence from the University of Southern California andhis B.S. degree in Information and Computer Sciencefrom the University of California Irvine. He has re-ceived numerous awards for his research contribu-tions, including the National Science Foundation CA-REER award, the GMU Emerging Researcher/Schol-ar/Creator award, and the GMU Computer ScienceDepartment Outstanding Faculty Research Award. Heis a member of the ACM, ACM SIGSOFT, and IEEE.

ieee transactions on software …lilicoding.github.io/sa3repo/papers/2015_bagheri2015covert.pdfit...

Documents