SDLI: Static Detection of Leaks Across Intents
Total Page：16
File Type：pdf, Size：1020Kb
2018 17th IEEE International Conference On Trust, Security And Privacy In Computing And Communications/ 12th IEEE International Conference On Big Data Science And Engineering SDLI: Static Detection of Leaks across Intents Rocco Salvia Pietro Ferrara Fausto Spoto Agostino Cortesi School of Computing JuliaSoft SRL Universita` di Verona DAIS University of Utah Verona, Italy and JuliaSoft SRL Universita` Ca’ Foscari Salt Lake City, Utah, USA pietro.ferrara@ Verona, Italy Venice, Italy [email protected] juliasoft.com [email protected] [email protected] Abstract—Intents are Android’s intra and inter-application real world apps from the Google Play marketplace, where its communication mechanism. They specify an action to perform, ability to deal with implicit intents uncovers dangerous flows. with extra data, and are sent to a receiver component or Finally, the analysis is soundy [9], since it inherits the power broadcast to many components. Components, in the same or in a distinct app, receive the intent if they are available to and precision but also the limitations of Julia [17], [10] and of perform the desired action. Hence, a sound static analyzer must most static tools that analyze real software (typically because be aware of information flows through intents. That can be of reflection and multithreading). achieved by considering intents as both source (when reading) This article is organized as follows. Sec. II discusses the and sink (when writing) of confidential data. But this is overly state of the art on intent analysis. Sec. III presents the structure conservative if the intent stays inside the same app or if the set of apps installed on the device is known in advance. In such cases, of Android apps and the use of intents. Sec. IV recalls Julia’s a sound approximation of the flow of intents leads to a more flow analysis and shows its application to Android. Sec. V precise analysis. This work describes SDLI, a novel static analyzer presents the novel intent analysis. Sec. VI reports experiments. that, for each app, creates an XML summary file reporting a Sec. VII concludes. description of the tainted information in outwards intents and of the intents the app is available to serve. SDLI discovers confidential information leaks when two apps communicate, by II. RELATED WORK matching their XML summaries, looking for tainted outwards intents of the first app that can be inwards intents of the Most analyses dealing with intents focus on a limited set second app. The tool is implemented inside Julia, an industrial of components only, typically activities. Some analyze the static analyzer. On some popular apps from the Google Play Android Dalvik (.dex) bytecode directly, others first translate it marketplace, it spots inter-apps leaks of confidential data, hence into Java bytecode or other intermediate language, then perform showing its practical effectiveness. Index Terms—Information Flow, Static Analysis, Abstract the analysis [16]. We now compare our approach to some of Interpretation, Android, Intent. the most notable tools. FlowDroid [2] performs taint analysis on .dex files. It collects I. INTRODUCTION sources and sinks using SuSi [15] and it considers any method This article reports design and implementation of a novel that sends intents as a sink and any call that extracts data intent analysis that detects sensitive information flows across from an intent as a source. It does not deal with implicit different Android applications (apps) and its integration inside intents nor with intent modifiers, unless they are constant the Julia static analyzer. Our analysis warns when an intent strings. Epicc [13] performs a sound static analysis of Android carries sensitive data from one app to another. Hence, it tracks apps in Java bytecode, translated from .dex code through intent flows both between components and between apps. It Dare [11]. It focuses on inter-component communication uses Julia’s flow analysis for tracking flows of tainted data, through intents, also between different apps. It deals with using an abstraction in terms of Boolean formulas to express intent filters statically specified in the manifest but also with all possible explicit flows of tainted data [5]. Starting from dynamically registered broadcast receivers. The analyzer does a set of sources of tainted user input, it establishes if tainted not always detect such receivers in a sound way, because of data flows into sensitive sinks. intrinsic limitations of the tool: no static fields, no reflection, SDLI is the implementation of such analysis, on top of the limited string analysis. IccTA [8] identifies sources and sinks Julia analyzer. For each app, SDLI computes a soundy XML with SuSi, like FlowDroid. It translates Dalvik bytecode into summary file reporting a description of the tainted information Jimple [18], by using Dexpler [3]. It can leverage on both in outwards intents and of the intents the app is available Epicc or its extension IC3 [12] to obtain the inter-component to serve. By matching pairs of XML files, one can discover communication methods and their parameters (IC3 is preferred leaks of confidential information when two apps communicate, due to its performance). It deals with the dynamic registration by checking if an output tainted intent can pass the app’s of broadcast receivers. Finally, IccTA applies FlowDroid to boundaries and reach another app. perform an intra-component taint analysis. The authors report The main novelty of our analysis is that it considers all kinds that IccTA performs also an inter-app communication, but do of Android’s components and both implicit and explicit intents. not show any result. In any case, IccTA inherits the same Moreover, it has been widely evaluated over a large set of limitations of Epicc and IC3. 2324-9013/18/31.00 ©2018 IEEE 1002 DOI 10.1109/TrustCom/BigDataSE.2018.00141 new this class Intent download = Intent( , DownloadService. ); 1 public class MainActivity extends Activity { download.setData(Uri.parse(fileUrl)); 2 public void sendMessage(View view) { startService(download); 3 String textMessage = telephonyManager.getDeviceId(); Fig. 1. Creation of an explicit intent for starting a DownloadService. 4 Intent send = new Intent(); 5 send.setAction(Intent.ACTION_SEND); 6 send.putExtra(Intent.EXTRA_TEXT, textMessage); 7 startActivity(send); III. ANDROID APPLICATIONS AND INTENTS 8} 9} This section describes the structure of Android apps Fig. 2. An activity with an event handler that creates an implicit in- and their communication model through intents. Exam- tent for sending a message. This is inside an app called App1. The constants Intent.EXTRA_TEXT="android.intent.extra.TEXT" ples are from https://developer.android.com/guide/components/ and Intent.ACTION_SEND="android.intent.action.SEND" are intents-filters.html, where the reader can find further detail. hardcoded in the Android OS. Android supports a modular definition of apps in terms of <activity android:name="ShareActivity"> cooperating components, that can be independently developed <intent-filter> <action android:name="android.intent.action.SEND"/> and replaced as long as their interface is honored. This </intent-filter> interface is published in a manifest. Components can be </activity> user interface screens (activities), background tasks (services), 1 class ShareActivity extends Activity { data resolvers (content providers) or generic event listeners 2 protected void onCreate(Bundle savedInstanceState) { (broadcast receivers). An app can invoke its own components, 3 Intent intent = getIntent(); 4 String data = intent.getString(Intent.EXTRA_TEXT); but also exported components of other apps. 5 Log.i(data); A component starts another component by instantiating an 6} 7} Intent object that describes the required task. The intent can Fig. 3. A manifest (above) specifying that the activity ShareActivity be so precise to explicitly name the target component (explicit (below) is willing to fulfill Intent.ACTION_SEND actions (the value of intent) or it can just provide a high-level description, that that constant is explicitly reported in the intent filter). These snippets are from will go through dynamic resolution of the right component an app called App2. (implicit intent). The component is resolved and started static intent filter. The started activity recovers (a clone of) the by passing the intent to methods startActivity() starting intent through its getIntent() method, as shown or startActivityForResult() (for activities), in the same figure. Together, Fig. 2 and 3 form a running startService() (for services) or startBroadcast() example that will be used throughout this article to show a (for broadcast receivers). Content providers are started by data flow between apps. passing intents to a content resolver. Example 1 (Running Example): App1 (Fig. 2) creates an Intents can carry the arguments qualifying the required task, implicit intent with constant action Intent.ACTION_SEND called action. Hence, they are a sort of dynamic component and with extra, for the constant key Intent.EXTRA_TEXT, invocation with parameter passing. It follows that any sound bound to sensitive data (the device identifier). It uses this intent static analysis must be aware of how intent resolution works, to start an activity. App2 registers a matching activity in its in order to follow data propagation between components. But manifest (Fig. 3), through an intent filter that dispatches the this is a complex and highly-dynamic process. intent to the component ShareActivity. The latter reads To specify an intent, the programmer sets four properties: the extra for key Intent.EXTRA_TEXT and logs it. If both (i) an optional, fully qualified name of the target component apps are installed in the same device, they could collaborate class. If provided, this string uniquely identifies the target com- so that App2 catches the intent sent by App1 and leaks the ponent (explicit intent). Otherwise (implicit intent) component device identifier to the logs, even though App2 has no explicit resolution uses the subsequent three properties; (ii) a string access to the device identifier. specifying the desired action (such as view, send, pick); (iii) the URI referencing data to process, with its MIME type; and IV.