WIXLIB

process requires data to flow across isolated (sandboxed) applications.2.1.1ComponentsAndroid apps can be composed of one or more of the following components: An activity, which provides a screen with which users can interact to perform a task A service, which can perform long-running operations in the background and doesnot provide a user interface A content provider, which manages access to a central repository of data A broadcast receiver, which allows apps to register for system and application events2.1.2IntentsThe primary method for inter-component communication, both within and between applications, is via intents. For the photo-sharing example, the information (a photo) can flowacross multiple components via intents as follows:intentintentCameraApp activity PhotoEditingApp activity Social NetworkingApp activityAn intent can be an explicit intent for which the sender explicitly states the receivingcomponent, or an implicit intent, for which the intent specifies the action to perform and thecategory or data on which the action should be performed. The Android OS determines thereceiver on the basis of the intent filters defined in the manifest file of all apps installed onthe device. Every app has a manifest file, AndroidManifest.xml, which contains informationabout all components and their capabilities. The intent filters are used by the Android OSto determine if any components within the app are eligible to receive a particular implicitintent. It uses a set of filter-matching rules1 while resolving such intents. A componentmay also send an intent to itself. A component can be made accessible to other apps bysetting the exported attribute in the manifest file to true. If the exported attribute ntents-filters.html#Resolution6

not defined, the OS makes the component available to other apps by default if an IntentFilter is associated with the component. Access to this component can be restricted byusing permissions. Permissions are also declared in the manifest file, and a component canbe accessed by an app only if it has the required permission. Permissions are granted bythe user during the app installation and are enforced by the OS at runtime.How Intents Are UsedIntents can be used to launch activities; to bind, start, and stop services; and to broadcast information to broadcast receivers. Intents can be sent and received only betweenactivities, services, and broadcast receivers and not between content providers. Table 2.1lists commonly used methods to send intents to and receive intent results from activities.We use the term “startActivity family” to define methods that can be used to launchactivities.PurposeLaunch an activityLaunch an activity andexpect to receive a resultReturn data to the callerRead result set by the calleein callerMethod signaturestartActivity (Intent intent)startActivity (Intent intent, Bundle options)startActivityForResult (Intent intent, int requestCode)startActivityForResult (Intent intent, int requestCode,Bundle options)setResult (int resultCode)setResult (int resultCode, Intent data)onActivityResult (int requestCode, int resultCode,Intent data)Table 2.1: Commonly used intent-related methods for inter-activity communicationHow Intents Can Be MisusedVarious studies [17, 18, 19] done in the past have highlighted how intents can be misused tocarry out component hijacking and intent-spoofing attacks. Component hijacking attacksoccur when a malicious app receives an intent that was intended for another app butnot explicitly designated for it, that is, when implicit intents are used. The attack can7

result in leakage of sensitive data when the intent is received by an unintended recipient.Intent-spoofing attacks, by contrast, can be used to send spoofed commands (via intents)to legitimate apps, causing loss of secure control of the affected apps.2.2Static AnalysisStatic analysis is a program analysis method in which the source code (or bytecode) isanalyzed without executing it. Dynamic analysis, on the other hand, involves studying theapplication behavior by running it in an environment, for instance, analyzing an Androidapp by running it on an Android device.Static analysis allows examining all possible execution paths in the program, not justthose invoked during execution. This is especially valuable in security analysis, because attacks often exploit apps in unforeseen and untested ways. However, predicting the programbehavior without executing it is a nontrivial problem. By reducing it to the halting problem,it is possible to prove that finding all possible ways of executing any arbitrary nontrivialprogram is an undecidable problem. That is, there cannot possibly be any program thatwill always correctly predict the program behavior. However, static analysis can provideuseful results by approximating some facets of the actual execution of a program [20].One of the techniques of implementing static analysis is analyzing the data flow. Taintanalysis is a special type of data-flow analysis that tracks data along the program executionpath. In this technique, sensitive data is marked with a taint at the source, and this taintis allowed to propagate further through all program execution paths. Presence of this taintat predefined sinks is used to establish a flow between the source and the sink. This flowcan be used to detect sensitive data leaks from source to sink.2.2.1Static Analysis ToolsOur analysis is built upon the FlowDroid and Epicc analyses and the Soot framework.8

FlowDroidFlowDroid is an open-source static analysis tool for Android apps that is context-, flow-,object-, field-sensitive and lifecycle-aware [11]. It uses an IFDS (interprocedural, finite,distributive, subset) framework [21], which reduces the program analysis problem to asimple graph reachability problem. It accurately models the Android life-cycle, includingcallback methods (more detail next paragraph), and precisely maps the user-defined UIelements with the code. These features make FlowDroid highly sound and precise.Analyzing Android apps is more complicated than analyzing Java programs becausethese apps run within the Android framework. Java programs have a single entry point,the main() method. But Android apps can have multiple entry points, that is, callbackmethods that are implicitly called by the Android framework. These methods are notdirectly connected in the app source code. FlowDroid precisely handles this problem bycreating a dummyMain() method, which accurately emulates the Android lifecycle for eachcomponent by connecting the callback methods. It extends the Soot framework to obtaina precise call graph based on Heros [22], an IFDS framework implementation. Sources andsinks are identified on the basis of the information provided by SuSi [23].FlowDroid can precisely detect intra-component data flows, but it cannot detect intercomponent data flows involving intents.EpiccThe Epicc tool precisely and efficiently analyzes the inter-component communication (ICC).It reduces the discovery of ICC to an instance of the IDE (interprocedural distributive environment) data flow problem. IDE is an extension of the IFDS problem that extends thegraph reachability problem to a value-computation problem. It identifies properties (suchas action, category, and data MIME type) of intents that can be sent and received bycomponents [13]. For example, Epicc might identify that a particular app can send intentsonly with action android.intent.action.VIEW and MIME data type image/jpg.9

SootSoot [24] is a Java optimization and analysis framework. It provides four intermediaterepresentations for analyzing and transforming Java and Android bytecode. As mentionedpreviously, static analyses can analyze these intermediate representations more efficientlythan analyzing actual source code or bytecode. Soot also enables construction of precisecontrol-flow graphs (CFGs) that provide abstract model of programs.We use the Soot framework in several parts of our analyzer, described in Chapter 4.2.3Motivating ExampleIn section 2.1, we used a simple photo-sharing example to briefly demonstrate why appsneed to share data with each other. In this section, we discuss a motivating app set inwhich apps share data using intents. Figure 2.1 shows how the sensitive data can flow fromthe source to the sink only after traversing through multiple apps.Listing 2.1 shows the code that is executed when the user clicks on a button in activityMainActivity in the SendSMS app. It reads the device ID (source) and stores it in anintent using the putExtra() method. Finally, the startActivityForResult() methodtakes that intent as an argument to start a new activity.Figure 2.1: Data leak via an intent between SendSMS.apk and Echoer.apk10

123456789101112131415public class Button1Listener implements OnClickListener {private final MainActivity act;public Button1Listener(MainActivity parentActivity) {this.act parentActivity;}public void onClick(View arg0) {Intent i new Intent(Intent.ACTION SEND);i.setType("text/plain");TelephonyManager tManager (TelephonyManager) this.act.getSystemService(Context.TELEPHONY SERVICE);String uid tManager.getDeviceId();// SOURCEi.putExtra("secret", uid);// write sensitive data to Intentthis.act.startActivityForResult(i, 0);// outgoing Intent}}Listing 2.1: SendSMS.button1listener.javaBecause the target component for the intent is not specified (it’s an implicit intent), theOS must find an activity that can handle it. With the help of the intent filters defined inthe manifest files of all installed apps, the OS chooses the app that can handle this intent.Listing 2.2 shows that the Echoer app can handle this intent.12345678910111213. activityandroid:name "echoer.MainActivity"android:label "@string/app name" intent-filter action android:name "android.intent.action.SEND" / category android:name "android.intent.category.DEFAULT" / data android:mimeType "text/plain" / /intent-filter /activity .Listing 2.2: AndroidManifest.xml in Echoer.apkThe Echoer app receives the intent by using the getIntent() method, as shown in Listing 2.3. Intent i is stored as a class field inside the MainActivity class.11

12public class MainActivity extends Activity {Intent i;3protected void onCreate(Bundle savedInstanceState) (R.layout.activity main);Button button1 (Button) ner(new Button1Listener(this));}protected void onResume(){super.onResume();i getIntent(); // read data received in Intent from the callerBundle extras i.getExtras();Log.i("Data received in Echoer: ", extras.getString("secret"));// SINK}.45678910111213141516171819}Listing 2.3: Echoer.MainActivity.javaThe onClick() callback method shown in the Listing 2.4 is called when the user clicks onthe button button1 and sends the received data (Intent this.act.i) back to the caller ofthis activity (SendSMS) by using setResult(). A callback method onActivityResult()inside SendSMS is called when it receives the result, as shown in Listing 2.5.12345678910public class Button1Listener implements OnClickListener {private final MainActivity act;public Button1Listener(MainActivity parentActivity) {this.act parentActivity;}public void onClick(View arg0) {this.act.setResult(0, this.act.i); // send received data back to the callerthis.act.finish();}}Listing 2.4: Echoer.button1listener.java12

1234567891011121314151617public class MainActivity extends Activity {protected void onCreate(Bundle savedInstanceState) (R.layout.activity main);Button button1 (Button) ner(new Button1Listener(this));}.protected void onActivityResult(int requestCode, int resultCode, Intent data) { //incoming Intent ecret"));}protected void sendSMSMessage(String message) {SmsManager smsManager ("1234567890", null, message, null, null);// SINK}}Listing 2.5: SendSMS.MainActivity.javaFinally, the intent data is sent out via an SMS using the sendTextMessage() method.This completes the inter-app data flow that originates at line 11 (source) in Listing 2.1and gets leaked at line 15 (sink) in Listing 2.3 within the SendSMS app but via the Echoerapp.None of the existing tools, including FlowDroid, can detect such inter-component dataflows. A more sound and precise inter-component data-flow analysis is required. In thenext chapter, we present our analysis design, which aims at tracing such data flows.13

14

Chapter 3Analysis DesignThe overview of our analysis method is shown in Figure 3.1. Our goal is to produce a setof all possible source-to-sink flows within a set of Android apps. The taint flow analysistakes place in two phases. In phase 1, each application is analyzed individually. Receivedintents are considered sources; sent intents are considered sinks. The output of the phase1 analysis, for each app, consists of (1) flows within each component, found by FlowDroid;(2) identification of the properties of sent intents, as found by Epicc; and (3) intent filtersof each component, extracted from the manifest file.An intent ID is assigned to every source code line that sends an intent (that is, a sourcecode line that consists of a call to a method in the startActivity family), as described inSection 4.1.1. Sent intents with distinct IDs are considered distinct sinks, whereas intentswith the same ID are combined.Phase 2 of the analysis can be carried out on a subset of apps, using the output ofphase 1. The output of phase 2 consists of all the source-to-sink flows found in the set ofapps.15

SourceSourceComponent 1FlowDroidComponent dEpiccSinkFlowDroidEpiccFigure 3.1: Analysis by data flow type: FlowDroid identifies sources (including intentsreceived), flow of the data within the component, and sinks (including intents sent). Epiccidentifies characteristics of intents sent by a component. TaintFlows, the analyzer, matchessent intent characteristics to components that could receive the intent, using app manifestdata and matching intent IDs from Epicc and FlowDroid. A component could have zeroor more sources, sinks, intents received, and intents sent. From beginning to end, a givendata flow could be internal to one component or traverse multiple components, which couldbe in a single app or in multiple apps.src 1sink 1I1C1R(I1 )C2I3src 3sink 3C3R(I3 )Figure 3.2: Running example described in Section 3.1. R(Ii ) denotes the response to intentIi (set using setResult()).16

Figure 3.3: Interaction between C1 and C2 in the running example3.1Example ScenarioThis section introduces an example of information flows between multiple components(Figure 3.2) that cannot be precisely analyzed by existing tools. Suppose that componentC1 sends data to component C2 and receives data from it in return. Component C3 interactswith C2 in a similar fashion. These three components can belong to different apps or to asingle app. As depicted in Figures 3.2 and 3.3, for i {1, 3}:1. Component Ci calls startActivityForResult() to send data from source src i tocomponent C2 via intent Ii .2. Component C2 reads data from intent Ii and sends that data back to component Ciby calling setResult().3. Component Ci , in method onActivityResult(), reads data from the result andwrites it to sink sink i .The analysis should determine that (1) information flows from src 1 to sink 1 (but not sink 3 ),and (2) information flows from src 3 to sink 3 (but not sink 1 ). Note that FlowDroid by itselfcannot produce a result this precise even if the three components are part of a single app.17

3.2Phase 1In this phase, each app is analyzed individually. An intent is identified by a tuple of(sending component, receiving component, intent ID). An intent sent from C1 to C2 withID id is denoted by I(C1 , C2 , id ).In phase 1, when a component calls a method in the startActivity family, the recipientof the intent is unknown (because each app is analyzed in isolation in phase 1, and therecipient can be a component in another app), so we use null for the recipient field. Likewise,in the onCreate() method, we do not know the sender of the intent, so we use null forthe sender field. If a component receives an intent I1 and returns information via thesetResult() method, we denote the returned information by R(I1 ).CWe write source sink to denote that information flows from source to sink in component C. For this purpose, we treat intents as both sources (in the component thatcreates and sends the intent) and sinks (in the component that receives the intent). Usingthis notation, we represent the phase 1 equations for the flows depicted in Figure 3.2 anddescribed in Section 3.1 as follows:C1src 1 I(C1 , null, id 1 )C1R(I(C1 , null, null)) sink 1C2I(null, C2 , null) R(I(null, C2 , null))C3src 3 I(C3 , null, id 3 )C3R(I(C3 , null, null)) sink 3The flows constitute the desired output of the FlowDroid analysis. Although all the flowsin the running example involve intents, in general our analysis will also find flows fromnon-intent sources to non-intent sinks.We focus, in both description and implementation, on intents sent and received byActivity components; other types of components (services, content providers, broadcastreceivers) can be handled similarly.18

3.3Phase 2After all apps in a set have been analyzed, we enter phase 2. Our goal is to discoverhow tainted information can flow between components. For each sent intent, we find allpossible recipients, and we instantiate the phase 1 flow equations (which have missingsender/receiver information) for all possible sender/receiver pairs, as we describe in detailin Section 3.3.1. For the running example, the phase 2 flow equations are as follows:C1src 1 I(C1 , C2 , id 1 )C1R(I(C1 , C2 , id 1 )) sink 1C2I(C1 , C2 , id 1 ) R(I(C1 , C2 , id 1 ))C2I(C3 , C2 , id 3 ) R(I(C3 , C2 , id 3 ))C3src 3 I(C3 , C2 , id 3 )C3R(I(C3 , C2 , id 3 )) sink 3Let T (s) denote the taint of s, that is, the set of sensitive sources from which s potentiallyhas information. The goal of the analysis is to determine the taint of all sinks. Eachphase 2 flow equation s1 s2 relates the taint of s1 to the taint of s2 . If data flows from s1to s2 , then s2 must be at least

2.1 Android Overview Android apps are written in the Java programming language and are compiled to a Dalvik bytecode using the Android Software Development Toolkit (SDK). The SDK enables the developer to create an application package (APK), which is an archive with the .apk exten-sion. This APK le can be installed on Android devices.