FlowDroid: Precise Context, Flow, Field, Object-sensitive and Lifecycle-aware Taint Analysis for Android Apps
S Arzt，S Rasthofer，C Fritz
Today’s smartphones are a ubiquitous source of private and confi-dential data. At the same time, smartphone users are plagued by carelessly programmed apps that leak important data by accident,and by malicious apps that exploit their given privileges to copy such data intentionally. While existing static taint-analysis approaches have the potential of detecting such data leaks ahead of time, all approaches for Android use a number of coarse-grain approximations that can yield high numbers of missed leaks and false alarms.
In this work we thus present FLOWDROID, a novel and highly precise static taint analysis for Android applications. A precise model of Android’s lifecycle allows the analysis to properly handle callbacks invoked by the Android framework, while context, flow, field and object-sensitivity allows the analysis to reduce the number of false alarms. Novel on-demand algorithms help FLOWDROID maintain high efficiency and precision at the same time.
We also propose DROIDBENCH, an open test suite for evaluating the effectiveness and accuracy of taint-analysis tools specifically for Android apps. As we show through a set of experiments using SecuriBench Micro, DROIDBENCH, and a set of well-known Android test applications, FLOWDROID finds a very high fraction of data leaks while keeping the rate of false positives low. On DROIDBENCH, FLOWDROID achieves 93% recall and 86% precision,greatly outperforming the commercial tools IBM AppScan Source and Fortify SCA. FLOWDROID successfully finds leaks in a subset of 500 apps from Google Play and about 1,000 malware apps
from the VirusShare project.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org.
1. Introduction
According to a recent study [9], Android has seen a constantly growing market share in the mobile phone market, which is now at 81%. With Android phones being ubiquitous, they become a worthwhile target for attacks on users’ privacy-sensitive data. Felt et al. classified different kinds of Android malware [12] and found that one of the main threats posed by malicious Android applications are privacy violations which leak sensitive information such as location information, contact data, pictures, SMS messages, etc. to the attacker. But even applications that are not malicious and were carefully programmed may suffer from such leaks, for instance when they contain advertisement libraries [16]. Many app developers include such libraries to obtain some remuneration for their efforts, but few of them fully understand their privacy implications, nor are they able to fully control which data these libraries process. Common libraries distill private information that identifies a person for targeted advertisement such as unique identifiers (e.g., IMEI, MAC-address, etc.), country or location information.
Taint analyses address this problem by analyzing applications and presenting potentially malicious data flows to human analysts or to automated malware-detection tools which can then decide whether a leak actually constitutes a policy violation. These approaches track sensitive “tainted” information through the application by starting at a pre-defined source (e.g. an API method returning location information) and then following the data flow until it reaches a given sink (e.g. a method writing the information to a socket), giving precise information about which data may be leaked where. The analyses can inspect the app both dynamically and statically. Dynamic program analyses, though, require many test runs to reach appropriate code coverage. Moreover, current malware can recognize dynamic monitors as the analyzed app executes, causing the app to pose as a benign program in these situations.
While static code analyses do not share these problems, they run the risk of being imprecise, as they need to abstract from program inputs and to approximate runtime objects. The precise modeling of the runtime execution is particularly challenging for Android apps, as those apps are no stand-alone applications but are actually plugins into the Android framework. Apps consist of different components with a distinct lifecycle. During an app’s execution, the framework calls different callbacks within the app, notifying it of system events, which can start/pause/resume/shutdown the app etc. [17]. To be able to effectively predict the app’s control flow, static analyses must not only model this lifecycle, but must also integrate further callbacks for system-event handling (e.g., for phone sensors like GPS), UI interaction, and others. As we show in this work, recognizing callbacks is anything but trivial and requires dedicated algorithms. Another challenge is posed by sources of sensitive information such as password fields in the user interface. The respective API calls returning their contents cannot be detected based on the program code alone. Instead, their detection requires a model of auxiliary information stored in the manifest and layout XML files. Last but not least, like any application written in Java, Android apps also contain aliasing and virtual dispatch constructs. Typical static analyses for Java handle these problems through some degree of context and object sensitivity. The framework nature of Android makes this problem harder than usual, as we found it to expose extraordinarily deep aliasing relationships.
Past data-flow analysis approaches for Android [14, 15, 24, 40] handle the above challenges in an unsatisfactory manner using coarse-grained over- as well as under-approximations. Underapproximations, usually caused by the lack of a faithful lifecycle model, can cause these analyses to miss important data flows. In practice even worse, though, the tools’ over-approximations can cause many false warnings, easily overwhelming security analysts to the point at which they stop using the analysis tools entirely.
In this work, we therefore present FLOWDROID, a novel static taint-analysis system specifically tailored to the Android platform, and based on novel on-demand algorithms that yield high precision while maintaining acceptable performance. FLOWDROID analyzes the apps’ bytecode and configuration files to find potential privacy leaks, either caused by carelessness or created with malicious intention. Opposed to earlier analyses, FLOWDROID is the firststatic taint-analysis system that is fully context, flow, field and object-sensitive while precisely modeling the complete Android lifecycle, including the correct handling of callbacks and userdefined UI widgets within the apps. This design maximizes precision and recall, i.e., aims at minimizing the number of missed leaks and false warnings. To obtain deep context and object sensitivity while maintaining acceptable performance, FLOWDROID uses a novel on-demand alias analysis. The analysis algorithm is inspired by Andromeda [37] but improves over Andromeda’s in terms of precision. We have open-sourced FLOWDROID in summer 2013. The tool has already been picked up by several research groups and we are in contact with a leading producer of anti-virus tools, who plans to use FLOWDROID productively in the analysis backend.
For us and others to be able to measure scientific progress in this important field of research it is required that researchers are able to conduct comparative studies of Android taint-analysis tools. Unfortunately, up until now there exist no benchmarks that would allow for systematic studies. As another contribution of this work we thus make available DROIDBENCH, a novel open-source microbenchmark suite for comparing the effectiveness of taint analyses for Android. We have made DROIDBENCH available online in spring 2013 and know of several research groups who have used it already to measure and improve the effectiveness of their Android analysis tools [19]. A first group of external researchers has already agreed to contribute further micro benchmarks to the suite [35].FLOWDROID can be used to secure in-house developed Android apps as well as assist in the triage of Android malware. Both use cases demand not a perfect but yet a reasonably low rate of false positives and false negatives. A set of experiments with SecuriBench Micro, DROIDBENCH and some well-known apps containing data leaks shows that FLOWDROID finds a very high fraction of data leaks while keeping the rate of false positives low. On DROIDBENCH 1.0, FLOWDROID achieves 93% recall and 86% precision, greatly outperforming the commercial tools AppScan Source [2] and Fortify SCA [3]. Further experiments with real apps confirm FLOWDROID’s utility in practice.
We start by giving a motivating example and then explain the attacker model this work assumes. The example in Listing 1 (abstracted from a real-world malware app [42]) implements an activity, which in Android represents a screen in the user interface. The app reads a password from a text field (line 5) whenever the framework restarts the app. When the user clicks on a button of the activity, the password is sent via SMS (line 24). This constitutes a tainted data flow from the password field (the source) to the SMS API (the sink). In this example, sendMessage() is associated with a button in the app’s UI, which is triggered when the user clicks the button. In Android, listeners are defined either directly in the code or in the layout XML file, as is assumed here. Thus, analyzing the source code alone is insufficient—the analysis must also process the metadata files to correctly associate all callback methods. In this code a leak only occurs if onRestart() is called (initializing the user variable) before sendMessage() executes.
To avoid false negatives, a taint analysis must model the app lifecycle correctly, recognizing that a user may indeed hit the button after an app has restarted. To avoid false positives, an analysis of this example must be field sensitive: the user object contains two fields for the user name and password, but only the latter of which should be considered a private value. Object-sensitivity, while not required for this example, is essential to distinguish objects originating at different allocation sites but reaching the same code locations. In our experiments we found some cases requiring deep object sensitivity to be able to automatically dismiss false positives. This is due to the relatively deep call and assignment chains of the Android framework. Operations such as string concatenation (line 19) require a model that defines whether and how data flows through those operations. Treating such operations as normal method calls and analyzing library methods like application code can be imprecise it ignores the operations’ semantics) and, as we found, is often forbiddingly expensive in practice.