Embed Size (px)
Citation preview
Automatic Detection of Inter-application Permission Leaksin Android Applications
Technical Report TR13-02, Department of Computer Science, Rice University, January 2013
Dragos SbîrleaRice University
Michael G. BurkeRice University
Salvatore GuarnieriIBM Watson Research Center
Marco PistoiaIBM Watson Research Center
Vivek SarkarRice University
ABSTRACTDue to their growing prevalence, smartphones can access anincreasing amount of sensitive user information. To betterprotect this information, modern mobile operating systemsprovide permission-based security, which restricts applica-tions to only access a clearly defined subset of system APIsand user data. The Android operating system builds upon al-ready successful permission systems, but complements themby allowing application components to be reused within andacross applications through a single communication mecha-nism, called the Intent mechanism.
In this paper we identify three types of inter-applicationIntent-based attacks that rely on information flows in appli-cations to obtain unauthorized access to permission-protectedinformation. Two of these attacks are of previously knowntypes: confused deputy and permission collusion attacks. Thethird attack, private activity invocation, is new and relieson the existence of difficult-to-detect misconfigurations intro-duced because Intents can be used for both intra-applicationand inter-application communication. Such misconfiguredapplications allow protected information meant for intra-application communication to leak into unauthorized ap-plications. This breaks a fundamental security guaranteeof permissions systems: that applications can only accessinformation if they own the corresponding permission.
We formulate the detection of the vulnerabilities on whichthese attacks rely as a static taint propagation problem basedon rules. We show that the rules describing the permission-protected information can be automatically generated thoughstatic analysis of the Android libraries - an improvement overprevious work. To test our approach we built PermissionFlow,a tool that can reliably and accurately identify the presenceof vulnerable information flows in Android applications.
Our automated analysis of popular applications found that56% of the top 313 Android applications actively use inter-component information flows; by ensuring the absence ofinter-application permission leaks, the proposed analysiswould be highly beneficial to the Android ecosystem. Of thetested applications, PermissionFlow found four exploitablevulnerabilities.
1. INTRODUCTIONUsers of modern smarphones can install third-party appli-cations from markets that host hundreds of thousands ofapplications [1, 2] and even more from outside of officialmarkets. To protect sensitive user information from these po-tentially malicious applications, most operating systems usepermission-based access-control models (Android [3], Win-dows Phone 7 [4], Meego [5] and Symbian [6]).
Permissions are a well known and powerful security mech-anism, but - as with any new operating system - there isthe possibility that Android-specific features may reduce theguarantees of the classic permissions model. One such fea-ture is the new communication mechanism (called Intents),which can be used to exchange information between com-ponents (called Activitys) of the same application or ofdifferent applications.
One attack that exploits Intents for malicious purposes ispermission collusion. In this attack, an application thatindividually only has access to harmless permissions aug-ments its capabilities by invoking a collaborating applicationthrough sending and receiving Intents. To stage this attack,malevolent developers could trick users into installing suchcooperating malicious applications that covertly compromiseprivacy.
A second type of attack using Intents is the confused deputyattack. Confused deputy attacks rely on misconfigured appli-cations; components that interact with other applications areinvoked by unauthorized callers and allow them to performprotected actions or access permission-protected information.
We discovered a third type of attack, private activity invoca-tion, which is a more virulent form of the confused deputyattack: it affects applications not meant to communicate
with other applications. Even if a developer’s intention wasto disallow external invocation of internal Activitys, otherapplications may be able to invoke them if the applicationdoes not have the necessary configuration. This is possiblebecause Intents can be used for inter-application invocationsas well as intra-application invocations.
One possible approach for leveraging static analysis to dis-cover these vulnerabilities is to merge the call graph ofeach application and to enhance it with edges represent-ing the possible call edges between applications. On thisinter-application call graph, one could check using static taintanalysis whether protected information leaks to applicationsthat do not own the required permissions. However, this ap-proach could be time-consuming because of the large numberof applications that must be analyzed together.
We propose an alternative approach that first summarizes thepermission-protected APIs of the Android libraries. Then,using taint analysis, it tracks the information flow throughboth the Android libraries and the application, checking if theinformation reaches a misconfigured or otherwise vulnerablecomponent that allows permission-protected information toescape to other applications.
Tested on 313 popular Android Market applications, ourtool, PermissionFlow, identified that 56% of them use inter-component information flows that may require permissions.Four exploitable vulnerabilities were found. The structure ofthe paper is the following. The relevant parts of the Androiddevelopment model and permission system are described inSection 2. Section 3 illustrates possible attack scenarios.
We express the vulnerabilities as a taint propagation prob-lem in Section 4 and in Section 5 we present the design ofour analysis. Its main components are the Permission Map-per, which summarizes the protected information sourcesaccessible to any application, and the Rule Generator, whichgenerates taint rules that specify vulnerable flows; these rulesserve as input for our static analysis engine. We experimen-tally evaluate our analysis in Section 6. We further discussour experimental findings, and make recommendations forAndroid application security, in Section 7. Section 8 is ded-icated to related work, and we conclude in Section 9. Ourcontributions are the following:
• We classify Intent-based vulnerabilities in Androidapplications, identifying a new variant of the confuseddeputy attack, and describe ways of protecting againstattacks.
• We developed PermissionFlow, a tool for discoveringvulnerabilities in the bytecode and configuration ofAndroid applications.
• We propose a novel approach for automatic generationof taint flow sources for permission-based systems byconsidering permission-protected APIs to be sourcesof taint. Our Permission Mapper improves on previ-ous work by performing fully automatic analysis forAndroid Java APIs.
• We evaluate PermissionFlow on leading Android Mar-ket applications and show that 177 out of the 313
applications tested would benefit from our tool. Per-missionFlow found three permission-protected leaks inwidely used applications and an additional vulnerabil-ity that allows leaking of information that should beprotected by custom permissions.
2. BACKGROUNDThe vulnerabilities we identify involve knowledge about theAndroid development model, the Android inter-process com-munication mechanism and its permissions system. Thesecomponents are the focus of the following subsections.
2.1 Android developmentAndroid applications are typically written in Java using bothstandard Java libraries and Android-specific libraries. OnAndroid devices, the Java code does not run on a standardJVM, but is compiled to a different register-based set ofbytecode instructions and executed on a custom virtual ma-chine (Dalvik VM). Android application packages, also calledAPK s after their file extension, are actually ZIP archivescontaining the Dalvik bytecode compiled classes, their asso-ciated resources such as images and the application manifestfile.
The application manifest is an XML configuration file(AndroidManifest.xml) used to declare the various compo-nents of an application, their encapsulation (public or private)and the permissions required by each of them.
Android APIs offer programmatic access to mobile device-specific features such as the GPS, vibrator, address book,data connection, calling, SMS, camera, etc. These APIs areusually protected by permissions.
Let’s take for example the Vibrator class: to use theandroid.os.Vibrator.vibrate(long milliseconds) func-tion, which starts the phone vibrator for a number of millisec-onds, the permission android.permission.VIBRATE must bedeclared in the application manifest, as seen on line 2 ofListing 1.
Application signing is a prerequisite for inclusion in theofficial Android Market. Most developers use self-signedcertificates that they can generate themselves, which donot imply any validation of the identity of the developer.Instead, they enable seamless updates to applications andenable data reuse among sibling applications created by thesame developer. Sibling applications are defined by adding asharedUid attribute in the application manifest of both, asseen in line 1 of Listing 1.
Activitys. The Android libraries include a set of GUI com-ponents specifically built for the interfaces of mobile devices,which have small screens and low power consumption. Onetype of such component is Activitys, which are windows onwhich all visual elements reside. An Activity can be a listof contacts from which the user can select one, or the camerapreview screen from which he or she can take a picture, thebrowser window, etc.
Intents. Applications often need to display new Activitys .For example, choosing the recipient of an SMS message is per-formed by clicking on a button that spawns a new Activity.
1 <mani fe s t package=”com . android . app . myapp” sharedUid=” u i d I d e n t i f i e r ”>2 <uses−permis s ion name=”android . permis s ion .VIBRATE” />3 <a c t i v i t y name=”MyActivity ”>4 <in tent− f i l t e r>5 <ac t i on name=”com . zx ing .SCAN” />6 <category name=”category .DEFAULT” />7 </ intent− f i l t e r>8 </ a c t i v i t y>9 </ mani f e s t>
Listing 1: An Activity declaration in AndroidManifest.xml with declarations of used permissions and anintent filter.
This Activity displays the contacts list and allows the userto select one. To spawn the new Activity, the programmercreates a new Intent, specifies the name of the target class,and then starts it, as shown in the following snippet:
In tent i = new In tent ( ) ;i . setClassName ( this , ”package . Ca l l e eAc t i v i t y ” ) ;s t a r tA c t i v i t y ( i ) ;
Usually the parent Activity needs to receive data from thechild Activity, such as - in our SMS example above - thecontact phone number. This is possible through the use ofIntents with return values, The parent spawns a child by us-ing startActivityForResult() instead of startActivity()and is notified when the child returns through a callback (theonActivityResult() function), as shown in Listing 2. Thisallows the parent to read the return code and any additionaldata returned by the child Activity.
1 void onAct iv i tyResu l t ( int requestCode , intresultCode , In tent data ) {
2 i f ( requestCode == CREATE REQUEST CODE){
3 i f ( resu l tCode == RESULT OK) {4 St r ing i n f o = i n t e n t . ge tSt r ingExtra (
”key ”) ;5 }6 }7 }
Listing 2: Code snipped showing how a calleraccesses information returned by a child Activity.
1 Intent i n t e n t = new In tent ( ) ;2 i n t e n t . putExtra ( ”key ” , ”my value ” ) ;3 this . s e tRe su l t (RESULT OK, i n t e n t ) ;4 f i n i s h ( ) ;
Listing 3: Code snippet showing how child Activityscan return data to their caller.
As shown in Figure 3, the child Activity needs to call thesetResult function, specifying its return status. If additionaldata should be returned to the parent, the child can attach anIntent along with the result code and supply extra key/valuepairs, where the keys are Java Strings and the values areinstances of Parcelable types, which are similar to JavaSerializable classes and include Strings, arrays and valuetypes.
Sending Intents to explicitly named Activitys , as describedabove, is called explicit Intent usage. Android also allowscreation of Intents specifying a triple (action, data type,category) and any Activity registered to receive those at-tributes through an intent-filter will be able to receive ofthe Intent. If there are multiple Activitys that can receivethe Intent, the user will be asked to select one.
The explicit Intent feature is mostly used in intra-applicationcommunication, as described in the following section, butcan be useful for inter-application communication too and itsexistence is the root cause of the vulnerabilities discoveredby us.
2.2 Inter-application Intents and data securityInter-process communication with Intents. Intentscan be used for communication between Activitys of thesame application or for inter-application communication. Inthe second case, Intents are actually inter-process message-passing primitives. To specify a subset of Intents that anActivity answers to, developers add to the application man-ifest an intent-filter associated with the Activity. Theintent-filter in Figure 1 specifies that MyActivity can beinvoked by sending an Intent with action com.zxing.SCAN;such an Intent is called an implicit Intent because it doesnot specify a particular Activity to be invoked. ImplicitIntents are created using the single parameter constructornew Intent(String).
Component encapsulation. Developers enable or disableinter-application invocation of their Activitys by setting thevalue of the boolean exported attribute of each Activity
in the application manifest. The behavior of this attributeis a detail that may be a source of confusion, as the mean-ing depends on the presence of another XML element, theintent-filter:
• If an intent-filter is declared and the exported at-tribute is not explicitly set to true or false, its defaultvalue is true, which makes the Activity accessible byany application.
• If an intent-filter is not declared and the exported
attribute is not set, by default the Activity is onlyaccessible through Intents whose source is the sameapplication.
An exception to the above rules is allowed if the developer
Figure 1: Before installing any application, the useris presented with a list of permissions that the ap-plication needs access to.
specifies the attribute sharedUid in the manifest file. Inthat case, another application may run in the same processand with the same Linux user ID as the current application.This addition changes the behavior of Activitys that arenot exported: they can be invoked not only from the sameapplication, but also from the sibling application with thesame user ID. Listing 1 shows the use of the sharedUserId
attribute.
It is important to realize that the intent-filter mechanismdoes not provide any security guarantees and is meant onlyas a loose binding between Activitys and Intents; anyActivity with an intent-filter can still be sent an explicitIntent in which case the intent-filter is ignored. Thepresence of this attribute, however, changes the behavior ofthe security-related exported attribute, as detailed above.We found that many developers overlook the security-relatedimplications when using intent-filters.
2.3 Android permissions systemFor a user, Android permissions are just lists of capabilitiesthat he or she has to accept before installing applications.
As seen in Figure 1, when installing an application from theofficial Android Market, the user is presented with a list ofpermission names, each with a short description.
From the point of view of the Android programmer, eachpermission provides access to one or more Android JavaAPIs that would otherwise throw an exception when used.Permissions also protect Android ContentProviders, whichare SQLite databases indexed using a URI. Different URIsmean different permissions might be needed to access thecorresponding data.
To request permissions, the developer needs to declare themin the application manifest, as seen in Listing 1, through anuses-permission attribute that specifies the exact permis-sion as a String value. Users have a reasonable expectationthat if they do not give permission to an application to accessinformation (for example, their contacts), that application
will not have access to that information through some othermeans.
3. ATTACKSAll Android applications with a graphical user interfacecontain at least one Activity, which means vulnerabilitiesrelated to Activitys can affect a majority of applications.All the vulnerabilities that we identify have in commonthe existence of information flows that are meant to allowchild Activitys to communicate with authorized parents,but can instead be used by unauthorized applications toaccess sensitive information without explicitly declaring thecorresponding permission.
We identified three different attack scenarios, discussed in thefollowing paragraphs and out tool, PermissionFlow, identifiesthe flow vulnerabilities that enable all of them. Permission-Flow validation can be used as a prerequisite for applicationsbefore being listed in Android Market and by developers toensure the security of their applications or by users.
Note that other operating systems sandbox applicationsand do not offer a mechanism for direct inter-applicationcommunication; in spite of this, some of these attacks arestill possible. For example, in iOS, the colluding applicationsattack can be performed through URL Schemes [7].
1. Attacks on misconfigured applications happen whenan attacker application installed on the device can exploitthe flows of a misconfigured application. If an applicationhas any one of the configuration parameter combinationslisted in Table 1 as high risk, then any application on thedevice can spawn it.
If in the application manifest an Activity is listed withan intent-filter and is not accompanied by a exported=
"false" attribute, any other application on the system caninvoke it. Then, in the absence of dynamic permission check-ing by the developer (not standard practice), informationreturned to the caller through the Intent result may com-promise permission-protected information, as no permissionis required of the caller.
In the example from Figure 2 (left), the user installed malev-olent application B (a music streaming app) with permissionto access the Internet. B can exploit the honest but miscon-figured contact manager application A by invoking ActivityA2 that returns the contacts; B can then send the contactsto a remote server. If A2 is built to reply to external requestsand it just failed to check that B has the proper permis-sion, then the attack is a classic confused deputy attack.However, because in Android Intents are also used as aninternal (intra-application) communication mechanism, it ispossible that A2 is not built for communicating with anotherapplication and is just misconfigured. This private activityinvocation is a more powerful attack than confused deputybecause it targets internal APIs and not only public entrypoints. These internal APIs are generally not regarded asvulnerable to confused deputy and so not they are not se-cured against it. Further, by increasing the number of APIsthat can be targeted, this attack increases the likelihood thatthe returned information is permission-protected (Protectedinformation tends to flow between internal components such
InvokedActivity
A2
InvokerActivity
A1invoke
returnvalues
InvokerActivity
B1
Misconfigured Application APermission: READ_CONTACTS
Malevolent Application BPermission set: INTERNET
returnvaluesinvoke
InvokedActivity
M1
InvokerActivity
N1
invoke
returnvalues
Application M from developer D
Permission:ACCESS_LOCATION
Compromised Application Nfrom developer D
Permission: SEND_SMS
Process P
InvokedActivity
T2
InvokerActivity
V1
invoke
returnvalues
Malevolent Application T from developer M
Permission:CAMERA
Malevolent Application Vfrom developer MD
Permission set: INTERNET
Figure 2: Possible attacks: internal Activity invocation or confused deputy, application sharing user ID witha compromised application (center) and permission collusion by malevolent applications (right).
as A1 and A2, even when it does not leave the application.)PermissionFlow allows developers to identify the existenceof permission-protected information flowing between compo-nents and use this information to properly configure theirapplications.
For Activitys that are designed to be invoked by unknownapplications, developers can ensure that callers own a set ofpermissions in one of two ways: declaratively (in the manifestfile, using the permission attribute of the Activity) or dy-namically (by calling the function checkCallingPermission(
String permission)). Note that the permission attributecan only be used to enforce a single permission and is dif-ferent from the uses-permission node in Listing 1, whichcontrols what permissions the application needs in order tofunction.
The safest approach is to completely disable outside accessto internal Activitys that may leak protected information.Table 1 shows the combinations of configuration parametersthat may lead to information leaks. Each of the combinationsalso lists if any callers are allowed for that Activity or ifthe Activity restricts access to only applications from thesame developer.
2. Collusion attacks obtain permission-protected infor-mation without requesting the permission, by exploitingthe combination of assignment of Android permissions ona per-application basis and the exchange of applicationsinformation without making this explicit to the user.
In Figure 2 (right), we show a scenario in which a user istricked by a malevolent developer MD into installing twoseparate applications, that seem to have little risk associatedwith them. For example, a camera application that doesnot require the Internet permission seems safe, as it cannotupload the pictures to the Internet. Similarly, a music stream-ing application that does not request the Camera permissionwould be acceptable. However, if the two applications aremalicious, the music streaming application can invoke thecamera application and send the pictures obtained from itremotely. The Android security system does not inform theuser of this application collusion risk.
Note that the camera application can include checks on theidentity of the caller, such that it returns the pictures to
no other application except the music streaming one, whichallows such colluding applications to pass a dynamic securityanalysis that invokes all possible Activitys and checks thereturned information.
3. Attack on applications sharing the user ID. Wehave not yet discussed an additional type of attack thatour approach can recognize, but is improbable in practicebecause of its narrow applicability. This type of attack is onsibling applications.
These attacks target honest developers who had one of theirapplications compromised through methods unrelated to ourwork, such as:
• The developer’s certificate is compromised (these areself-signed certificates, vulnerable to exploitation sincethey cannot be revoked [?]); the certificate can beused to sign and publish a malevolent update to anapplication N of that developer.
• One of the developer’s applications N is compromiseddirectly through some other vulnerability.
This vulnerability allows an attacker to access the permission-protected information of applications sharing the user IDwith the already compromised N. If N is configured to havethe same user ID as application M (as shown in Figure 2center), it can then obtain the information from M. To setup this attack, an attacker would need to control applicationN of developer D, N should have any exfiltration permission(sending short messages, accessing the Internet, etc.) and Nshould share user ID with an application by D that returnspermission-protected information. Then, N can invoke mostActivitys of M, even if M is configured according to therows with low risk level in Table 1. PermissionFlow candetect this vulnerability too.
4. TAINT PROPAGATIONWe express the problem of leaking permission-protected in-formation to other applications by tracking flows of sensitiveinformation (taints) inside each application from informa-tion sources protected by permissions to values that theseapplications return to callers.
The taint analysis uses the following sources and sinks:
Activity configuration Application configuration ConsequenceExported Intent-filter SharedUid Callers accepted Risk levelexported=“true“ present any any HIGHexported=“true“ absent any any HIGHexported=“false“ present set from same developer LOWexported=“false“ absent set from same developer LOWdefault present any any HIGHdefault absent set from same developer LOW
Table 1: Different configurations lead to different levels of vulnerability.
• Sources: the permission-protected APIs in the Androidlibraries. Additionally, there may be other sources,such as callbacks registered by the application to becalled when some events occur, for example when apicture is taken using the phone camera.
• Sink: Activity.setResult(int code, Intent intent).The Intent parameter of calls to this function is acces-sible to the caller of the current Activity, so any dataattached needs to be protected.
From a confidentiality perspective, applications must alsoprotect other types of sources that are not protected by anyof the standard permissions defined by Android, for examplecredit card numbers, account information, etc. This is doneby using custom permissions that protect the invocationof their Activitys. The relationship between the custompermission and the data or API it protects is not obvious, sothere is no way to automatically generate taint rules checkingfor custom permissions. PermissionFlow can track theseflows only through additional rules that apply to application-specific sources of taint.
5. SYSTEM DESCRIPTIONPermissionFlow has two main parts. The first one is a general,reusable taint analysis framework; the second consists of allother components, which are Android-specific.
To analyze real Android Market applications, whose sourcecode is usually not available, we support input in the formof Android binary application packages (APK files). Thismeans PermissionFlow can also be used by Android users,developers and security professionals.
The system design (Figure 3) consists of the following com-ponents:
• The Permission Mapper (labeled 1 in the Figure 3)builds a list of method calls in the Android API thatrequire the caller to own permissions. Its inputs are An-droid classes obtained by building the Android sourcecode, with any modifications or additions performedby the device manufacturer. Having the complete sys-tem code as input allows the mapper to extract allthe permissions-protected APIs that will be presenton the device. It builds a permissions map, whichmaps permission-protected methods to their requiredpermissions.
Permissions Map
1. Permission
mapper
2.Rule Generator
Taint Rules (for permissions)
3.Andromeda
Flows
Library .jars
Library .jarsAndroid Library .jars
Additional Taint Rules (for custom permissions)
Application Package (.apk)
DecompiledApplication (.jar)
4. Decompiler(dex2jar)
5. Extract Resources(ApkTool)
Binary Manifest (AndroidManifest,xml)
6. XML Extraction
XML Manifest (AndroidManifest,xml)
7. Decision Maker
Figure 3: The components of PermissionFlow
• The permissions map is passed to the Rule Gener-ator, which builds the taint analysis rules relatingthe sources in the map with their corresponding sinks.In our case, the only sink is the Activity.setResult
method with an Intent parameter.
• Our taint analysis engine, (labeled 3) reads the gen-erated rules and any extra rules manually added fordetecting application-dependent private information. Itoutputs the flows that take the protected informationfrom sources to sinks. For this it needs access to theapplication classes and the Android library classes. Thetaint analysis engine also needs access to the Androidlibrary, in order to track flows that go through it, forexample callbacks that get registered, Intents that getpassed to the system, etc.
• The dex2jar decompiler [8] (labeled 4) is used toextract from the application APK a JAR archive con-taining the application bytecode.
• To extract the binary application manifest from theapplication package we use the ApkTool [9] (labeled
5); the decompilation step needed to get the textualXML representation is performed by AXMLPrinter2[10] (labeled 6).
• The taint analysis engine outputs the flows from sourcesto sinks if there are any, but the presence of flows doesnot in itself imply that the application is vulnerable.The Decision Maker (labeled 7) looks for the pat-terns identified in Table 1 in the application manifestfile - these patterns correspond to misconfigurationsthat allows successful attacks to take place. If an ap-plication contains a vulnerable information flow and isimproperly configured, only then is it vulnerable.
Currently, all the described components are implemented,except the decision maker, whose role was performed throughmanual inspection.
5.1 The Permission MapperThe Permission Mapper matches function calls used for per-mission enforcement in the Android libraries to Androidlibrary functions that use these calls. In short, it uses staticanalysis to identify permission-protected methods and to mapthem to their required permissions; this analysis is indepen-dent of any application analysis and needs to be performedonly once for each input Android configuration.
Identifying sources of permission-protected information ischallenging because of a phenomenon known as the Androidversion and capability fragmentation. Android has under-gone a quick succession of 15 API improvements, some withmultiple revisions, most of which are still in active use today.Relying on the documentation to find which APIs requirepermissions would bind our analysis to a particular version ofAndroid whose documentation we used as input. Even moredifferences between Android APIs are introduced by hard-ware manufacturers such as Samsung and HTC who buildtheir own additions to Android (Sense and Touchwiz, respec-tively). These add-ons include everything from drivers andlibraries to user interface skins and new system applications,which leads to capability fragmentation. Because of fragmen-tation, when an application performs a call to a library thatis not distributed with the application, Android fragmenta-tion makes identifying which permissions are needed for thatcall very difficult, as the exact permissions may be differentdepending on the exact Android version and add-ons. Identi-fying sources of permission-protected information could alsobe attempted by crawling the documentation. However, it isincomplete even for public, documented classes and does notinclude public, but non-documented methods and does notaccount for Java reflection on non-public methods. It alsodoes not account for any modifications and additions to theAndroid API performed by the phone manufacturer. Previ-ous work [11] showed that it is possible to identify which APIcalls require permissions though a combination of automatedtesting and manual analysis, but they use techniques thatallow false negatives, need partial manual analysis and donot handle the version and feature fragmentation problem ofAndroid.
For these reasons, we built the Permissions Mapper, a reliableand automatic tool for identifying permission-protected APIsand their required permissions. The Permissions Mapper
1 public void v ib r a t e ( long time ) {2 i f ( mService == null ) {3 Log .w(TAG, ”Se r v i c e not found . ” ) ;4 return ;5 }6 try {7 mService . v i b r a t e ( time , mToken ) ;8 } catch ( RemoteException e ) {9 Log .w(TAG, ”Fa i l ed to v i b r a t e . ” , e ) ;
10 }11 }
Listing 4: Code snippet showing how API calls useservices to perform protected functionality.
takes as input the JAR archives of the Android distributionthat needs to be summarized, including any additional codeadded by the hardware manufacturer. This allows for acomplete analysis that works without user input and canreliably deal with API differences between various versionsof the OS.
In the Android libraries, several mechanisms are used toenforce permissions:
• Calls to the checkPermission function located in theContext and PackageManager classes orcheckCallingOrSelfPermission function located inthe Context class;
• Linux users and groups (used, for example when en-forcing the WRITE_EXTERNAL_STORAGE and BLUETOOTH
permissions);
• From native code (such as the RECORD_AUDIO or CAMERApermissions).
Our work targets complete coverage of APIs enforced throughthe first category, which includes the majority of Androidpermissions.
To illustrate how permission checks work, we can use forexample the VIBRATE permission. To use the phone vibrator,an application needs to own the VIBRATE permission; allfunctions that require this permission check for it. One suchfunction is Vibrator.vibrate, whose source code is shownin Figure 4. When this function is called, the Android APIforwards the call to a system service instance mService (line8), which executes in a different process from the application.The mService instance is returned by a stub of the vibratorservice:
mService = IV ib ra t o rS e rv i c e . Stub . a s I n t e r f a c e (ServiceManager . g e tS e r v i c e ( ‘ ‘ v i b r a t o r ”) ) ;
This is because in Android, developers build Android In-terface Definition Language (AIDL) interfaces, from whichremote invocation stubs are automatically generated [?], sim-ilar to Java RMI development.
The service process is the one that makes the actual permis-sion checks, before performing any protected operation, as
1 public class Vibra to rSe rv i c e extends I V i b r a t o r S e r v i c e . Stub {2 public void v ib r a t e ( long m i l l i s e c o n d s , b inder ) {3 i f ( context . checkCa l l ingOrSe l fPermi s s i on (VIBRATE) ) != PackageManager .PERMISSION GRANTED){4 throw new Secur i tyExcept ion ( ”Requires VIBRATE permis s ion ” ) ;5 }6 }7 }89 public class ContextImple extends Context {
10 public int checkCa l l ingOrSe l fPermi s s i on ( St r ing permis s ion ) {11 return checkPermiss ion ( permiss ion , Binder . ge tCa l l i ngP id ( ) , Binder . ge tCa l l ingUid ( ) ) ;12 }13 }
Listing 5: Code snippet showing how services check the permissions of the application.
shown in Listing 5.
The interprocedural dataflow analysis is built using IBMWALA[13] and starts by building the call graph of the An-droid libraries, including all methods as entry points. Allcall chains containing a Context.checkPermission(String)
method call are then identified. To find the actual permissionstring that is used at a checkPermission call site, we followthe def-use chain of the string parameter. Once found, welabel all callers upstream in the call chain as requiring thatpermission. Note that different call sites of checkPermissionwill have different permission strings - each such string needsto be propagated correctly upstream, building set of requiredpermissions for each function.
For the vibrate() example, the permission enforcementcall chain is in Figure 4. The string value of the vibrate
permission is located by following the def-use chain of thecheckPermission parameter (dashed lines) until the sourceString constant is found. Once the constant is found, weneed to identify which functions on the call chain need thispermission. We start by labeling the function that containsthe first (“most downstream”) call site through which thedef-use chain flows. In our case, the def-use chain goes firstthough the call site of checkCallingAndSelfPermission
in IVibratorService.vibrate (line 4 in Figure5), where the VIBRATE variable is specified as aparameter, so IVibratorService is labeled with“android.permission.VIBRATE”.
After labeling IVibratorService.vibrate, the same labelmust be propagated to callers of that function, but in ourcase there are no callers except the proxy stub.
Because the communication between Android proxy stubsand their corresponding services (shown as dotted edges inFigure 4) is done through message passing, it does not appearin the actual call chain built by WALA. To work aroundthis problem we add the permissions labels of the servicemethods to the corresponding proxies; the labels are thenpropagated to any callers of those methods.
5.2 Taint Rule GeneratorThe output of the Permission Mapper is a hash table mappingeach Android API function that needs permissions to the
Vibrator.vibrate(1000)
IVibratorService.vibrate(long millis)
Context.checkCallingOrSelfPermission(VIBRATE)
Contet.checkPermission(String s)
String permissions.VIBRATE = “android.permission.VIBRATE”
IVibratorService.Stub.Proxy.vibrate(long millis)
Figure 4: The permission analysis exemplified onthe vibrate() call
set of one or more permissions that it requires. The taintrule generator turns that information into rules usable bythe taint analysis engine.
The rules specify the tracked taint flows: from the sources inthe permissions map to the Activity.setResult function.The set of rules automatically generated in this way can bemanually augmented by providing additional rules describingwhat application data should be private (protected by customapplication permissions).
5.3 Taint Analysis EngineFor the taint analysis engine, we used Andromeda [14], whichis highly scalable and precise; it builds on IBM WALA [13].Andromeda uses as input rules composed of two sets: sourcesand sinks. The sources are parameters and return values offunctions that are the origin of tainted data and the sinks aresecurity-critical methods. The engine tracks data flow fromthe source through assignments, method calls, and otherinstructions, until the data reaches a sink method. If thetaint analysis engine discovers that tainted data reaches asink method, the flow is included in the taint analysis engineoutput.
6. EXPERIMENTAL RESULTS6.1 Evaluation of the permissions map
We evaluated the Android API Permissions Mapper by di-rectly comparing its output permissions map with that ofprevious work. The two approaches considered are that ofFelt et al. [11], based on automated testing, and that ofBartel et al.[?], based on static analysis. To perform thecomparison with the work by Felt et al. we eliminated permis-sions from their map that are enforced through mechanismsother than the checkPermissions calls, because our analysisonly targets checkPermissions-enforced permissions.
Comparing the size of their reference map (which includes1311 calls that require permissions) with ours (4361 callswith permissions) shows that our tool finds more functionsthat require permissions. The larger size of our map is partlyexplained by the lack of false negatives for the analyzed JavaAPIs. However, a direct comparison is not possible as theinput classes on which Felt et al. ran their analysis is notspecified in their paper. Our input was the full set of classesin the android.* and com.android.* packages, as well asJava standard classes that are used inside those (a total of40,600 methods). Our map also includes functions in internaland anonymous classes, which partially explains the highernumber of methods in the permissions map.
Through manual comparison, we identified one false negativein their map (probably due to the automated testing notgenerating a test and the subsequent analysis not detect-ing the omission). The function is MountService.shutdown,which usually needs the SHUTDOWN permission, but if the me-dia is shared it also needs the MOUNT_UNMOUNT_FILESYSTEMS
permission. The existence of missing permissions in thetesting-based methods shows that testing methods, even ifparty automated and enhanced by manual analysis, cannotoffer guarantees with respect to false negatives.
Another reason for the higher number of methods found inour map is the existence of false positives: permissions thatare reported as required but are not. We have identified thefollowing sources of false positives, all of which are knownweaknesses of static taint analysis:
• Checking for redundant permissions. For examplechecking for ACCESS_FINE_LOCATION orACCESS_COARSE_LOCATION inTelephonyManager.getCellLocation(), where eitherone is sufficient for enforcement; our method reportsboth, because it is oblivious to control flow.
• Data dependent checks. For example, a check for theVIBRATE permissions depends on the value of a param-eter such as in NotificationManager.notify().
• Android provides the pair of functions clearIdentity
and restoreIdentity that are used to change all checksso that they are performed on the service instead ofthe application using the service.
Another advantage of testing-based analysis is that it cancover areas, such as the permissions enforced in native code,which static analysis does not target (such as RECORD_AUDIO).
To perform a more detailed comparison of our approach withthe work by Felt et al., we compared results obtained for
a simple security analysis, identification of overprivilegedapplications, based on the permission map. This analysisconsists of identifying Android applications that request intheir manifest more permissions than they actually need toperform their functions. The results are used to reduce theattack surface of applications by removing unused permis-sions from the manifest. To perform this analysis, we builtanother static analysis tool based on IBM WALA, whichrecords the API calls that can be performed by an appli-cation and computes, based on the permissions map, thepermissions required by that application. The set of discov-ered permissions is then compared to the set of permissionsobtained from the application manifest ( obtained from thecompiled application package through the use of the AndroidSDK tool aapt).
We used both permission maps as input for the analysis of theTop Android Market Free Applications (crawled in December2011) that were compatible with Android 2.3 and available inthe US (354 applications). For a fair comparison, we removedfrom Felt et al.’s reference map the parts that relates contentprovider databases to their permissions, as these were outsidethe scope of our work. After eliminating applications thatcrashed the dex2jar [8] decompiler or generated incorrectbytecode, we were left with 313 applications. Of these, bothour analysis and theirs found 116 to be overpriviledged. Nopermissions identified as unused by us were identified asused by Felt et al., which is consistent with the lack of falsenegatives expected from a static analysis approach. However,47 permissions were identified as used by us and as unusedby Felt et al..
Comparison with Bartel et al. [?] was more difficult as theirresults are not publicly available. Their analysis focusedon Android 2.2, which has a slightly lower number of APIsand so a lower number of permission checks. Their resultsidentify a much smaller number of overprivileged applications:12% of applications are identified as vulnerable by Bartelet al., but the ratio, as identified by Felt, et al. is closerto 30%. We obtain a 37% rate, which is explained by ournot considering native code permissions. Bartel et al. havea similar disadvantage, which should have skewed the ratetowards higher values. This inconsistency may have beencaused either by their use of a call graph that is too impreciseor by using a different set of applications as input. Ouranalysis yields a result similar to Felt et al. and uses asimilar input (Android Market applications), whereas Bartelet al. used an alternative application store.
Regarding the performance of the tool, the Permissions Map-per runs in under two minutes on our dual core i5 (2.4GHz,8GB RAM) whereas their map takes two hours to build on aquad core (2.4GHz, 24GB RAM). The performance differencecan be explained in part by their trying to eliminate false pos-itives by ignoring permission checks between clearIdentity
and restoreIdentity calls in the kernel; however this tech-nique does not seem to improve accuracy for their experi-mental results and considerably increases execution time.
6.2 Evaluation of PermissionFlowWe tested PermissionFlow on the same applications used toevaluate the permission map. To confirm the correctness ofthe results we manually inspected all applications. Out of
the 313 applications, 177 use the Activity.setResult withan Intent parameter to communicate between components(both internal or external). These 56% of the applicationsmay be vulnerable if they also contain flows from taint sourcesto sinks and are not configured properly. They can usePermissionFlow to check that they are secure.
To check for correctness, we ran PermissionFlow with ourpermissions map and the one produced by Felt. Using themap from Felt, PermissionFlow correctly identified two ap-plications as vulnerable and had no false positives. Withthe permissions map built by our analysis, PermissionFlowoutputs a larger set of vulnerable applications, but the addi-tional applications are all false positives. As we saw in theprevious section both permissions maps are incomplete: oursdoes not track permissions enforced through non-Java mech-anisms and Felt’s allows the possibility of missing permissionchecks. Choosing one of the two maps amounts to eitherusing a possibly incomplete map (Felt, et al.) and finding nofalse positives, or identifying the complete set of Java-basedflows and accepting some false positives but missing flowsbased on native code or Linux permissions checks.
Our analysis may have false negatives for applications thatpass protected information between components before re-turning it; for example, Activity A may return protectedinformation to Activity B, which is improperly secured. Wecannot guarantee the identification of such cases becausethe use of implicit Intents prevents identification of theclass names for invoked Activitys. For implicit Intents,the receiving class depends on the manifest configurationof all applications installed on the system and may dependon user preferences (if there are multiple Activitys withthe same intent-filter the user is asked to select one thatshould be invoked). If one requires an analysis without falsenegatives, our analysis can convert the possible false nega-tives to possible false positives, by adding, as an additionalsource for the taint analysis, the Intent parameter of theonActivityResult callback.
In the following subsections we present the three vulnerableapplications discovered by our analysis that leak Androidpermission-protected information. Section 6.2.4 describesone more vulnerable application that leaks information whichshould be protected with custom permissions.
6.2.1 Case Study: Adobe Photoshop ExpressAdobe Photoshop Express contains an interesting vulnerableflow. The application has an Activity that displays a listof Contacts and allows the user to pick one. The flow startsfrom getContentResolver().query(
Contacts.CONTENT_EMAIL_URI), and reaches the user inter-face; from there, the handler for the Click operation buildsan Intent containing the email of the selected contact and re-turns it to the caller. In Android, read access to the Contactsdatabase is protected by the READ_CONTACTS permission andcallers of this Activity work around this restriction.
The exported attribute is not set and, because anintent-filter is present, the Activity is callable from anyapplication. It seems the developer used the intent-filter
as a security mechanism, which it is not. After disassem-bling the application and finding the appropriate category
attribute for the Intent and the Activity class name, anymalevolent developer can exploit it. Even if the user is re-quired to click a contact, there is no way for the user toidentify whether the Activity returns the information tothe legitimate caller (the Photoshop application) or someother application. Because the attack can be performed byany application, the risk in this case is high.
6.2.2 Case Study: SoundTrackingThe popular SoundTracking application allows users to sharea message to their social networks with the name of a songthey are listening to and their geo-location. Permission-Flow finds that it is vulnerable to leaking users’ geo-locationto other applications: the Activity responsible is markedwith an intent-filter, so any other application can invokeit. Manual analysis showed that no fewer than 43 differ-ent Activitys of this application have intent-filters, andthere is no evidence of dynamic or declarative permissionchecking, suggesting that the developers are confused as tothe proper use of the intent-filters. The risk level is high.
6.2.3 Case Study: Sygic GPS ApplicationThe Sygic GPS application allows users to take picturesusing an Activity developed in house, instead of reusingthe regular Android camera application. To do this, theActivity CameraActivity registers a callback using theCamera.takePicture function. The system invokes the call-back when the picture is taken and attaches the actual bytearray representing the image to it. It then calls setResult
and finish, sending the raw picture to the caller. However,the Activity has no intent-filter. Because the exported
attribute is not set, the default value is false. The Activity
could only be exploited by another application signed by thesame developer, so we classify it as low risk. For now, noneof the other applications of the same developer currentlyin the market seem to invoke this Activity, but this maychange in the future. This vulnerability is difficult to detectstatically because the source is not in the application code;the application passes a function to the camera API and theoperating system calls that function with tainted parameters(the picture array). The Intent passes through a messagequeue, from where it is forwarded to the correct applicationhandler. Identification of this vulnerability was possible be-cause we analyze the application together with the Androidlibraries and manually added a rule to PermissionFlow thatmarks the function that distributes the Intents to handlersas having a tainted Intent parameter.
6.2.4 Sensitive-information flowsMany applications have access to other types of sensitiveinformation that are not protected by standard Android per-missions. For example, a banking application needs to protectcredit card information and a social networking applicationneeds to protect family-related and location information. Toprotect this kind of information, developers should definecustom permissions, but because of the coarse-grained na-ture of the custom permissions (assigned to applications asopposed to APIs) it is not possible to automatically identifythe taint sources for such information. For this reason, Per-missionsFlow allows specification of additional rules to beused for identifying such vulnerabilities.
Through manual inspection of the market applications wefound proof that sensitive information often crosses inter-component boundaries. The existence of these flows showsthat PermissionFlow would be a useful tool for developers inconfiguring their application to not be vulnerable to leakingdata protected by either standard or custom permissions.
Some applications fail to protect this information properly.For example, Go Locker has a lockscreen passcode selectionActivity that can leak the phone lockscreen password. TheGo SMS application from the same developer has a similarflow, but the manifest contains the sharedUserId attribute,so it is exploitable. An attacker that can control anotherapplication with the same user ID can access the password.Because of the shared user ID restriction, we consider GOSMS as low risk.
Some of the inter-component flows of sensitive informationthat are not protected using standard permissions are de-scribed next. These applications are correctly configured, sothey are not vulnerable, but their developers could benefitfrom using our tool because they can easily check if theirapplications are protected. If the developers took steps toprotect sensitive information, these are listed in parenthesesafter the description of the flows.
• The WeatherChannel application contains an Activity
that can leak the name of the last recorded video orpicture from the camera.
• The Accuweather application can leak the location asselected by the user. Because the string representationof the location does not come from permission protectedAPIs, the automatically generated rules to not recog-nize it. However, adding a rules manually is possibleand enables detection of this kind of information flowviolations.
• Adobe Reader contains an ARFileList Activity thatreturns the absolute path to a file selected by the user(not exported, no intent-filter).
• The Facebook application and Facebook Messengerallow the user to select friends from the friends list andreturns their profiles, which contain their names, linksto their image, etc. (not exported, no intent-filter).
• HeyZap Friends has a TwitterLoginActivity that re-turns information received from the server after login(including username) that may contain information thatcan be used to compromise the privacy of the users’Twitter account (not exported, no intent-filter).
• The mobile CNN application has a similar Activity
that can leak the user postal code, after he selects itfrom a list (not exported, no intent-filter).
• The Kayak application leaks the user login email if theuser logins with the Login screen that the vulnerableapplication displays (not exported, no intent-filter).
• Launcher EX contains an Activity that returns thename of an installed application (not exported, nointent-filter).
• The GoContactsEX and the FunForMobile applications,contain Activitys that return contact information (nointent-filter, not exported).
• Google Translate has a flow that involves returning thetext of a user selected SMS message (not exported, nointent-filter) after the user selects one contact.
• The official Twitter application uses an Activity re-turn value to return the Twitter OAuth token thatallows access to the twitter API as the user that gener-ated it. The Activity is meant to be invoked by otherapplications (has an intent-filter ) and is safely con-figured through declarative permission enforcement.Two other web-related apps, PicsArt Photo Studio andIMDB, contain Activitys that return OAuth tokens,but are correctly protected.
• The official Hotmail app contains an Activity that re-turns the URI of an email, but the actual content has tobe fetched from a Content Provider that declarativelyenforces read and write permissions.
• The Walgreens application returns the path and nameto the picture taken by the camera. (no intent-filter,not exported).
7. DISCUSSION OF FINDINGSWe discovered three vulnerable permissions-leaking appli-cations that may compromise information protected by theCAMERA, READ_CONTACTS and either ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION permissions.
We also found 70 applications containing flows that needprotection but are correctly configured; around 23% of theAndroid Market applications could use our analysis to confirmproper configuration. As 177 applications had Activitys thatreturned extra information, 56% of the applications coulduse our tool to pinpoint if they need to secure their protectedinformation against such attacks. PermissionFlow identifiedall vulnerable applications correctly and had one false positive(because of a bug we are currently investigating); howeverit reached the 30 minutes time-out on 4 (non-vulnerable)applications.
All the vulnerabilities discovered require the user to performsome action using the GUI of an application that was notexplicitly started. This should look highly suspicious to asecurity-conscious user, making successful attacks less likelyto succeed. However, it is easy to perform a similar attackthat does not require user intervention and regular users maybe easily tricked.
During our manual analysis we paid special attention toapplications that handle financial information such as creditcard information and online shopping account details andfound that these application generally use Intents only forconfirmation and not for communication of sensitive informa-tion such as PINs, credit card numbers or passwords. Otherapplications, such as the ones in the case studies above areindeed vulnerable.
We did not find any trace of malevolent attacks performedby the top Android Market applications; most applications
correctly configure internal Activitys by not supplying anexported="true" attribute or an intent-filter.
We believe that part of the cause of the vulnerabilities is thecomplexity of properly configuring an Android application,as three attributes are involved: exported, intent-filterand sharedUid are not easy to get right.
The complexity involved increases the need for safe defaults.Our recommendation is that Android should require, bydefault, that any caller of a third-party application must ownthe permissions required by the callee. This would mean thatany Intent invocation loses any possible permission collusioncapability and only serves as a code reuse mechanism.
For applications such as Barcode Reader that effectivelysanitize their data, the developer could add permission at-tributes to the manifest that lists permissions that shouldnot be needed from callers (whitelist instead of blacklist).
Another helpful but larger change would be for inter- andintra-application Intent flows to use separate APIs; thiswould reduce developer confusion and split a large attacksurface into smaller chunks that can be protected each withappropriate tools.
7.1 Recommendations for secure applicationsThe first and most important advice for security-aware An-droid developers is to pay close attention to the configura-tion of their application (specifically, any combination ofparameters listed in Table 1 is, without additional checks,vulnerable). If such a parameter combination is needed forfunctionality reuse or other constraints, here are some waysof maintaining security:
• A safe approach is to always request explicit user con-firmation for the invocation of any Activity that maybe part of an inter-application flow. The user should beinformed to which caller the information will be sent.This method has the disadvantage that it decreases theease-of-use of the application.
• To enforce that callers of your Activitys own cer-tain permissions, developers can use either declarativepermission requirements in the application manifestand dynamic permission checks using checkPermission
calls. (both are shown in Section 3)
• Developers should consider using work-arounds for send-ing sensitive information over inter-component bound-aries. For example, several of the applications analyzedleak information from an ordered set of items such ascontact names/phone number or zip code. For theseapplications there is no need for complex mechanismsto avoiding the vulnerability; it may be sufficient toreturn an integer index to the information database,instead of the actual information; the caller would needto query the database to obtain the actual information.
• Passing sensitive information over inter-componentboundaries of the same application in an encryptedform is recommended to protect against unintended
callers, but does not help if an attacker has compro-mised another application with which the current ap-plication shares the user id.
8. RELATED WORKPrivilege escalation attacks on Android applications havebeen previously mentioned in literature [16]. However, suchan attack requires usage of native code, careful identificationof buffer overflow vulnerabilities and high expertise. Wefocus only on vulnerabilities specific to Android and helpprotect the information before such attacks happen.
Michael Grace et al. [17] focused on static analysis of stockAndroid firmware and identified confused deputy attacksthat enable the use of permission-protected capabilities. Ouranalysis is complementary in that it identifies not actionsthat are performed, but information that flows to attackers.Also we focus not on stock applications, but third-partyapplications.
TaintDroid [18] uses dynamic taint tracking to identify infor-mation flows that reach network communication sinks. BothPermissionFlow and TaintDroid can potentially support othersinks, and their dynamic approach is complementary to ourstatic approach because it can better handle control flow (forexample, paths that are never taken in practice are reportedas possible flows by our tool). It can also enforce only safeuse of vulnerable applications by denying users the capabilityto externalize their sensitive information.
SCanDroid [19] is the first static analysis tool for Androidand can detect information flow violations. The tool needsto have access to both the vulnerable application and theexploitable application. To the best of our knowledge, SCan-Droid is not easily extensible with new taint propagationrules. ComDroid [?] is the first tool that analyses inter-application communication in Android. However, it reportswarnings which may or may not be vulnerabilities. Auto-matic rule and permission map generation, as well as analysisof the dangers of using the same mechanism for both intra-and inter-application communications, are contributions thatseparate our work from theirs.
Mann and Starostin [?] propose a wider analysis based ontyping rules that can discover flow vulnerabilities. They haveno experimental results on applications and did not realizethat private components are vulnerable to inter-applicationattacks. With additional rules, PermissionFlow can analyzeall vulnerabilities suggested by them.
A different aspect of the inter-application flow vulnerabilitiesis described by Claudio Marforio et al. whose work focusedon colluding applications[?]; they identified several possiblecovert channels through which malevolent applications cancommunicate sensitive information, for example by enumerat-ing processes using native code or files. Most of them howeverare not Android-specific, no tool was built to prevent them,and no vulnerable or malevolent application was found. Thecontribution of the work consists of identification of the dan-ger of colluding applications for modern permission-basedoperating systems. Our analysis identifies when permission-protected information leaves the application, but this may beneeded to perform the function of the application. Hornyack
et al. [20] propose a system that replaces protected infor-mation with shadow data and they concluded that 34% ofapplications actually need to leak information to performtheir function. A combination of PermissionFlow and theirtool might lead to better protection of the user privacy, whilemaintaining functionality.
9. CONCLUSIONThis paper proposes a solution for the problem of checkingfor leaks of permission-protected information; this is animportant security problem as such leaks compromise users’privacy.
Unlike previous work, our method is completely automated;it is based on coupling rule-based static taint analysis withautomatic generation of rules that specify how permissionscan leak to unauthorized applications. We demonstratethe benefits of this analysis on Android, and identify theIntent mechanism as a source of permission leaks in thisoperating system; we found that permissions can leak toother applications even from components that are meant tobe private (i.e., accessed only from inside the application)through a more virulent form of confused deputy attack -private activity invocation.
Our automated analysis of popular applications found that56% of the top 313 Android applications actively use inter-component information flows. Among the tested applications,PermissionFlow found four exploitable vulnerabilities. Be-cause of the large scale usage of these flows, PermissionFlowis a valuable tool for security-aware developers, for securityprofessionals and for privacy-conscious users. Our approachextends beyond Android, to permission-based systems thatallow any type of inter-application communication or remotecommunication (such as Internet access). Most mobile OSesare included in this category and can benefit from the pro-posed new application of taint analysis. By helping ensurethe absence of inter-application permission leaks, we believethat the proposed analysis will be highly beneficial to theAndroid ecosystem and other mobile platforms that may usesimilar analyses in the future.
10. REFERENCES[1] Research2Market, “Android market insights september
2011.”http://www.research2guidance.com/shop/index.
php/android-market-insights-september-2011,2011.
[2] Apple, “IPhone App Store,” Accessed December 2011.
[3] Google, “Android security guide.”http://developer.android.com/guide/topics/
security/security.html, 2012.
[4] Microsoft, “Windows Phone 7 Security Model.”http://www.microsoft.com/download/en/details.
aspx?displaylang=en&id=8842, 2012.
[5] The Linux Foundation, “Meego help: Assigningpermissions.” http://wiki.meego.com/Help:
Assigning_permissions, Accessed December 2011.
[6] Nokia, “Symbian v9 security architecture.”http://library.developer.nokia.com/, 2012.
[7] Passing data between iOS applications,http://kotikan.com/blog/posts/2011/03/
passing-data-between-ios-apps.
[8] Opensource, “Dex2jar google code repository.”http://code.google.com/p/dex2jar/, AccessedDecember 2011.
[9] Opensource, “Android apktool google code repository.”http://code.google.com/p/android-apktool/.
[10] Opensource, “Java 2 me port of google android.”
[11] A. P. Felt, E. Chin, S. Hanna, D. Song, and D. Wagner,“Android permissions demystified,” in Proceedings of the18th ACM conference on Computer andcommunications security, CCS ’11, (New York, NY,USA), pp. 627–638, ACM, 2011.
[12] Android Fragmentation information,http://www.androidfragmentation.com/about.
[13] T. J. Watson Libraries for Analysis (WALA),http://wala.sourceforge.net.
[14] O. Tripp, M. Pistoia, P. Cousot, R. Cousot, andS. Guarnieri, “Andromeda: Accurate and ScalableSecurity Analysis of Web Applications,” in FASE, 2013.
[15] D. Sbırlea, M. Burke, S. Guarnieri, M. Pistoia, andV. Sarkar, “Automatic detection of inter-applicationpermission leaks in Android applications,” tech. rep.,Rice University, January 2013. http://www.cs.rice.edu/~vsarkar/PDF/PermissionFlow-TR.pdf.
[16] L. Davi, A. Dmitrienko, A.-R. Sadeghi, andM. Winandy, “Privilege escalation attacks on Android,”in Proceedings of the 13th international conference onInformation security, ISC’10, (Berlin, Heidelberg),pp. 346–360, Springer-Verlag, 2011.
[17] M. Grace, Y. Zhou, Z. Wang, and X. Jiang,“Systematic detection of capability leaks in stockandroid smartphones
”” in Proceedings of the 19th
Network and Distributed System Security Symposium(NDSS 2012), 2012.
[18] W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung,P. McDaniel, and A. N. Sheth, “Taintdroid: aninformation-flow tracking system for realtime privacymonitoring on smartphones,” in Proceedings of the 9thUSENIX conference on Operating systems design andimplementation, OSDI’10, 2010.
[19] A. P. Fuchs, A. Chaudhuri, and J. S. Foster,“SCanDroid: Automated Security Certification ofAndroid Applications,” Tech. Rep. CS-TR-4991,Department of Computer Science, University ofMaryland, College Park, November 2009.
[20] P. Hornyack, S. Han, J. Jung, S. Schechter, andD. Wetherall, “These aren’t the droids you’re lookingfor: retrofitting android to protect data from imperiousapplications,” in Proceedings of the 18th ACMconference on Computer and communications security,CCS ’11, (New York, NY, USA), pp. 639–652, ACM,2011.
Biographical SketchesDragos Sbırlea Department of Computer Science, RiceUniversity 6100 Main Street, Houston, Texas, 77005([email protected]). Mr. Sbirlea is a Ph.D. Candidate inthe Habanero Multicore Software Research group at RiceUniversity. He is the author or co-author of 5 scientificpublications. His research interests include analysis andoptimization of parallel programs. He is a contributor to theSandia Qthreads library and a member of ACM (Association
for Computing Machinery).
Michael G. Burke Department of Computer Science, RiceUniversity 6100 Main Street, Houston, Texas, 77005([email protected]). Dr. Burke has been a Senior ResearchScientist in the Computer Science Department at Rice Uni-versity since 2009. He received a B.A. degree in philosophyfrom Yale University in 1973, and M.S. and Ph.D. degreesin computer science from New York University in 1980 and1983, respectively. He was a Research Staff Member in theSoftware Technology Department at the IBM Thomas J.Watson Research Center from 1983 to 2009, and a managerthere from 1987 to 2000. His research interests include pro-gramming models for high performance parallel and big datacomputing, and static analysis-based tools for: programminglanguage optimization; database applications; mobile secu-rity; compiling for parallelism. He is an author or coauthor ofmore than 50 technical papers and 11 patents. Dr. Burke isan ACM Distinguished Scientist and a recipient of the ACMSIGPLAN Distinguished Service Award. He is a member ofIEEE (Institute of Electrical and Electronics Engineers).
Salvatore Guarnieri IBM Software Group, P.O. Box 218,Yorktown Heights, New York 10598 ([email protected]).Mr. Guarnieri is a Software Engineer in the Security Divisionof IBM Software Group, and a Ph.D. student in the Depart-ment of Computer Science of University of Washington. Heis an author or co-author of six scientific publications. Hisresearch interests include program analysis and security ofscripting languages.
Marco Pistoia IBM Research Division, Thomas J. WatsonResearch Center, P.O. Box 218, Yorktown Heights, New York10598 ([email protected]). Dr. Pistoia is a Manager andResearch Staff Member at the IBM T. J. Watson ResearchCenter, where he leads the Mobile Technologies group. Hehas worked with IBM for seventeen years. He holds a Ph.D.in Mathematics from New York University, Polytechnic Insti-tute, and a Master of Science and Bachelor of Science degreein Mathematics from the University of Rome, Tor Vergata,Italy. His research interests include program analysis, pro-gramming languages, security, and mobile technologies. He isan author or coauthor of ten books, thirty technical papers,fourteen patents and sixty-eight patent applications, andthe recipient of two ACM SIGSOFT Distinguished PaperAwards.
Vivek Sarkar Department of Computer Science, Rice Uni-versity 6100 Main Street, Houston, Texas, 77005([email protected]). Prof. Sarkar is a Professor of ComputerScience and the E.D. Butcher Chair in Engineering at RiceUniversity. He conducts research in multiple aspects of par-allel software including programming languages, programanalysis, compiler optimizations and runtimes for paralleland high performance computer systems. Prior to joiningRice in July 2007, Vivek was Senior Manager of ProgrammingTechnologies at IBM Research. His past projects includethe X10 programming language, the Jikes Research VirtualMachine for the Java language, the ASTI optimizer used inIBM’s XL Fortran product compilers, the PTRAN automaticparallelization system, and profile-directed partitioning andscheduling of Sisal programs. Vivek became a member ofthe IBM Academy of Technology in 1995, was inducted as
an ACM Fellow in 2008. He holds a B.Tech. degree fromthe Indian Institute of Technology, Kanpur, an M.S. degreefrom University of Wisconsin-Madison, and a Ph.D. fromStanford University.
