figure a
figure b

1 Introduction

Mobile applications (“apps”) are often designed as a collection of specialized components that rely on each other to implement functionality for the end user. Thus, inter-app communication features prominently in their implementations, and mobile operating systems offer a variety of communication primitives that are sufficiently flexible to work in an open ecosystem of apps. Unfortunately, ease of communication also brings risks of introducing information flow security bugs and vulnerabilities that are hard to prevent, detect, and fix.

A concrete instance of this problem occurs in the popular Android mobile operating system, which provides intents for flexible, asynchronous inter-app coordination. An app that wants to delegate an operation (for example, opening a web page) to another app instantiates an intent object specifying the operation and the data needed to execute it (for example, the web page’s URL), and registers the object with the Android operating system. Any other app that is capable of executing the operation (for example, a web browser) can receive that intent object from the system and handle its request. This kind of implicit communication between apps is suitable for programming in an open ecosystem, where the app that makes a request (instantiating the intent object) does not need to know which apps can handle it (receiving the intent object). However, it may also introduce unintended leaks of sensitive information [14, 17, 18, 22, 24, 26]: the sender has no way of specifying the sensitivity of the data packed within an intent, nor can it know in advance which apps will receive and how they will handle the intent. Conversely, the receivers do not know whether they are handling sensitive data, nor which privacy policies the sender app would like to enforce.

In this paper, we propose IntentRepair: an automated technique to detect information leaks that originate in inter-app intent-based communication, and to automatically repair them by enforcing a preferred security policy. As we better discuss in Sect. 5, IntentRepair ’s focus is quite novel: plenty of existing work [5, 6, 12, 17, 18, 24, 26] deals with detecting information-flow security violations in intent communication, but most of it focuses on intra-app communication. Furthermore, to our knowledge, no other work features the automated repair of such security flaws.

To detect leaks, IntentRepair creates a summary of any app’s usage of intents—whether the app sends or receives intent objects, for which operations, and the information flow of the intents’ data. Then, it matches senders and receivers for the same operation to identify possible information leaks—when a sender’s sensitive data is sent to a sink in the receiver. Unlike most existing approaches, IntentRepair does not just detect information leaks but can also automatically repair them. The key idea is to repair both the senders—adding a sensitivity declaration to any data they add to intent objects—and the receivers—checking that the received data is handled according to the sender’s preferred policy. To achieve high precision, IntentRepair combines static analysis of Android bytecode with dynamic taint analysis, which validates whether certain information flow are actually possible at runtime.

We implemented the IntentRepair technique in a tool with the same name. We evaluated it on 14 Android open-source apps from the DroidBench [1] and RepoDroid [21] curated collections, as well as on 855 larger open-source apps from the FDroid repository. The experimental evaluation demonstrates that IntentRepair can analyze apps of realistic size, successfully detect scenarios of insecure intent-based inter-app communication, and automatically generates patches that avoid the information-flow security bugs.

In summary, this paper makes the following contributions:

  • IntentRepair: an automated technique to detect and repair information flow privacy leaks in Android apps.

  • A prototype implementation of IntentRepair  [25].

  • An experimental evaluation of IntentRepair on 869 Android apps.

2 Preliminaries

This section provides an overview of inter-app communication and its challenges in Android apps. First, Sects. 2.1 and 2.2 introduce the basics of Android apps and intent communication; then, Sect. 2.3 details the challenges in detecting and repairing the information flows via intents.

2.1 Android Basics

Android applications are usually written in Java or Kotlin, and consist of a collection of components of four kinds: activities, broadcast receivers, services, and content providers [4]. Activities usually implement user interfaces, such as a login screen. System and application events, such as boot-up notifications, are broadcasted to components registered as broadcast receivers. Services are active in the background and designed for lengthy or computationally intensive tasks, such as downloading a file in the background. Content providers shuffle data from one app to another by various means.

Each app contains a manifest file AndroidManifest.xml, which includes essential information, such as the app’s name, its components, and any libraries it depends on. The manifest also specifies an app’s permissions, that is the features of the Android operating system (and of the device that runs it) that the app may access.

2.2 How Intent Communication Works

Android provides intents as a flexible communication means between components. In a nutshell, intents implement a form of message-passing communication based on the component’s capabilities (called “actions” in Android parlance).

Precisely, Android intents support two ways of addressing, that is of identifying the recipients of a message. With explicit intents, the sender explicitly specifies the component(s) that may receive the message; no other components are allowed to receive it. With implicit intents, the sender does not specify any explicit recipients, but rather an action (for example, opening a web page);Footnote 1 the Android system will dispatch the message to any components that support the action specified by the sender. In other words, implicit intents support a kind of implicit, capability-based addressing.

Explicit and implicit intents provide different trade offs between ease of communication and control over the recipients. Sending sensitive data via explicit intents is generally safe, in that the sender generally knows exactly who will receive that data (and how they will use it). In contrast, sending sensitiveFootnote 2 data via implicit intents may be risky, since the sender of an implicit intent generally does not know exactly who will receive the data until when the app actually runs. Thus, enforcing privacy rules during app development is a challenge when using implicit intents; tackling this challenge is the main focus of the present work.

Fig. 1.
figure 1

Android code of sender and receiver apps communicating through implicit intents.

Full size image

2.3 An Example of the Challenges of Implicit Intent Communication

Figure 1 illustrates the risks of implicit intent communication through a simple example. Two sender apps each create an intent object for custom action : app S in Fig. 1a includes some sensitive data in the object—the host mobile device’s unique identifier (also known as IMEI number). App N in Fig. 1b, instead, only includes information that is not sensitive.

Figure 1c shows the code of another app R, which is capable of handling action .Footnote 3 In a system where all three apps S, N, and R operate, Android would dispatch the intent messages sent by S and N to R, which would then retrieve the data and re-send it through a public channel (i.e., in a text message—Line 24 in Fig. 1c).

Such a scenario has two potential problems in terms of information-flow security. First, S is not aware that R sends its sensitive data to a public channel. Second, R may not even have the necessary permissions to receive that sensitive data. Both problems originate in the flexible nature of implicit intent-based communication: the sender of an implicit intent cannot specify the sensitive nature of the data it sends; and the receivers of an implicit intent may access its data even if it contains information that is beyond their permissions.

Addressing these problems when implementing apps S, N, and R would be infeasible or too expensive, and fundamentally at odds with the flexibility introduced by implicit intents. The receiver app R cannot know, in general, the sensitivity of the data received through intents. Considering a priori all potential sender apps is also practically impossible in an open ecosystem of apps like Android. To address these issues, we propose a novel automated repair approach that works at app deployment time, which we describe in Sect. 3.2.

3 Methodology

This section presents our approach to automatically detect and repair information flow security leaks that originate with implicit intent communication. First, Sect. 3.1 introduces an abstract model of implicit intent-based communication; then, Sect. 3.2 gives an overview of our intent repair framework, followed by a detailed presentation of how its components work.

3.1 An Abstract Model of Implicit Intents

Before delving into the details of our framework, we present an abstract model of implicit intents. As is, Android offers a rich API for intent communication [3]. For example, there are 25 operations to initialize an intent object, 30 operations to add data to it, and 42 operations to extract data from it.

Fig. 2.
figure 2

\(\textsf{Tentative}\): An abstract model of intent programming.

Full size image
Fig. 3.
figure 3

An example of intent communication in \(\textsf{Tentative} \).

Full size image

In this paper, we only consider implicit intents, where the sender does not know precisely which components will receive an intent message, but only what actions the receivers can handle. Figure 2 shows the syntax of \(\textsf{Tentative}\): an abstract, minimal model of implicit intent communication, which we’ll use in the paper to simplify the presentation of the core technical concepts. \(\textsf{Tentative}\) provides statements to create an intent object for a certain action a (\(\texttt{createIntent}(a)\)), to add a key-value pair k, d to an intent object i (\(\texttt{put}(i, k, d)\)), to retrieve the data stored under k from an intent object i (\(\texttt{get}(i, k)\)), to send \(\texttt{send}(i)\) and receive \(\texttt{receive}(a)\) an intent object associated with action a, and to “sink” some information into a channel (\(\texttt{sink}(d, p)\))—public, or with some other security level p. In an Android app, the action associated with a receiver is declared in the receiver app’s manifest; in \(\textsf{Tentative}\), it is explicit in the call to \(\texttt{receive}\). Figure 3 shows two snippets of \(\textsf{Tentative}\) code modeling a basic sender and receiver: the sender in Fig. 3a captures the same behavior as Fig. 1a’s Android code; the receiver in Fig. 3b captures the same behavior as Fig. 1c’s Android code, where \(\texttt{sink}(\texttt {data}, \top )\) denotes that the is sent to a public sink.

3.2 How Intent Repair Works

Figure 4 pictures the overall workflow of our intent repair framework; Algorithm 1 presents its corresponding high-level algorithm. The input to the intent repair process is a set of Android apps—given as APK files—whose intent-based information flow communication will be analyzed. The first step is the receiver analysis (described in Sect. 3.2.1): for each app that receives implicit intent objects, we determine which actions it supports, and what it does with the data extracted from the intent objects—in particular, whether it leaks any of it to a sink. Assuming that at least one “potentially insecure” receiver exists, the next step is the sender analysis (described in Sect. 3.2.2), which summarizes the behavior of apps that send implicit intent objects—in particular, whether they include any sensitive data in the intents. The next step (described in Sect. 3.2.3) matches senders and receivers, identifying pairs (s, r) such that s sends sensitive information through implicit intents, r may receive such information and send it to a non-secure sink. For each such pair, the last step performs the actual repair: it patches the sender s so that it includes information about the permissions required to use the data it sends via implicit intents (as described in Sect. 3.2.4); and it patches the receiver r so that it retrieves this information and uses it to check that it has the necessary permissions to use the intent data (as described in Sect. 3.2.5).Footnote 4

Fig. 4.
figure 4

An overview of how IntentRepair works.

Full size image
Algorithm 1
figure f

IntentRepair ’s overall algorithm.

Full size image
Algorithm 2
figure g

Analysis of receivers: \(\textsf {ReceiverAnalysis}\).

Full size image

3.2.1 Receiver Analysis

Algorithm 2 outlines IntentRepair ’s receiver analysis. A receiver component is one that includes calls to the \(\texttt{receive}\) primitive (line 2).Footnote 5 IntentRepair taints the intent object for each such call to \(\texttt{receive}\), in order to find program locations that extract data from the object (primitive \(\texttt{get}\), line 3). Then, it also taints the data objects to determine if they flow into an insecure sink (line 4). If this is the case, all the collected information about the receiver is stored as the receiver summary (line 5).

Algorithm 3
figure i

Analysis of senders: \(\textsf {SenderAnalysis}\).

Full size image

3.2.2 Sender Analysis

Algorithm 3 outlines IntentRepair ’s sender analysis. A sender component is one that includes calls to the \(\texttt{send}\) primitive (line 2), which represents all variants of Android’s methods. For each such call to \(\texttt{send}\), IntentRepair computes the inter-procedural backward slice using the sent intent object as slicing criterion; thus, the slice will include all calls to the \(\texttt{createIntent}\) and \(\texttt{put}\) primitives that involve the sent intent object. IntentRepair considers all pairs of \(\texttt{createIntent}\) (line 3) and \(\texttt{put}\) (line 4) in the slice that target the same action. By analyzing the data that is stored by each \(\texttt{put}\), IntentRepair determines whether handling that data requires any non-trivial permission (line 5). If this is the case, all the collected information about the sender is stored as the sender summary (line 6).

3.2.3 Sender-Receiver Matching

Given a sender S’s summary \(\langle s, a_s, k_s, p \rangle \) and a receiver R’s summary \(\langle r, a_r, k_r \rangle \), matching them is straightforward: it amounts to determining if they send and receive intent objects associated with the same action (\(a_s = a_r\)), and exchange data using some shared key (\(k_s = k_r\)).

Fig. 5.
figure 5

Abstract Repairs for the Senders and Receivers

Full size image

3.2.4 Sender Repair

If at least one matching pair of sender and receiver exists, it means there is sensitive information that may flow to a sink; in this case, the repair process begins. The first step is “repairing” the sender, which means providing means of communicating its security policies to the receiver site Android provides no built-in mechanism to allow this kind of identification with intent objects—not even at runtime. To address this, we explicitly inject the intent object in the sender with additional data. The main idea is storing in the intent object pairs (k, p), where k is the key of a piece of data stored in the same object and p is the permission required to access that data.

Figure 5a illustrates this idea on the running example. Figure 1a’s sender includes in intent object sensitive data (an IMEI number) under key . Android permission is required to access this sensitive data; thus, IntentRepair injects the pair in the sender’s intent object, using a fresh, unique key .

3.2.5 Receiver Repair

As described in the previous section, IntentRepair injects intent objects on the sender’s side, so that the receivers know the required permissions. Correspondingly, IntentRepair modifies all receiver apps so that they retrieve this information about permissions and use it appropriately.

First, the receiver should have the required permissions to handle the intent object. If this is not the case, IntentRepair patches the receiver so that it asks the app user to upgrade its permissions. If the user denies the request, the app is not allowed to continue and can only abort its operations.

Once the receiver has acquired the necessary permissions—either statically or dynamically—IntentRepair still has to sanitize the sensitive data it received through the intent object before dumping it into a public sink, so as not to violate any information flow security rules. To this end, IntentRepair provides a simple anonymization of the data (which could also be used, in a pinch, in the scenario where the client lacks the necessary permissions). Within the same general repair scheme, one could implement custom declassification policies for the nature of the sensitive data; for instance, if the sensitive data is location information, the receiver could replace the precise location with an approximation. IntentRepair supports customizing how receiver apps are repaired, so as to enforce the app developers’ preferred policies and practices.

Figure 5b illustrates this idea on the running example. IntentRepair modifies Fig. 1b’s receiver so that it checks what permission is required to handle the data stored under key in intent object . If the receiver does not have nor cannot acquire permission , it simply terminates, so as to avoid any mishandling of sensitive information. Conversely, once it has acquired permission , it sanitizes the intent data before sending it to a public sink.

3.2.6 Repair Correctness

To make the presentation of IntentRepair ’s repairs rigorous, let’s extend \(\textsf{Tentative}\) with the set of fix ingredients shown in Fig. 6: IntentRepair can avoid an information-flow security flaw in a receiver by terminating its execution (\(\texttt{exit}\)), sanitizing sensitive data (\(\texttt{sanitize}\)), or requesting a permission (\(\texttt{request}\)). As for the rest of \(\textsf{Tentative}\), these operations generalize different Android library calls that can be used to change the permissions and a program’s information-flow security—as demonstrated in Fig. 5b’s example.

Fig. 6.
figure 6

Repair operations for \(\textsf{Tentative}\) intent programs.

Full size image
Fig. 7.
figure 7

Rules to check whether a \(\textsf{Tentative}\) program is information-flow secure.

Full size image

Figure 7 shows the main rules that formalize what it means for a \(\textsf{Tentative}\) program to be information-flow secure. To this end, a permission state P keeps track of the permission as a program executes; P is a pair (A, R), where A is the set of permissions the running app currently has, whereas R maps each variable v to the permission R(v) required to access that variable’s content.Footnote 6 Each rule in Fig. 7 has the form \(\langle s, P \rangle \rightarrow P'\), which denotes that executing statement s when the permission state is P is successful and leads to permission state \(P'\) (or to termination if ). A program is information-flow safe if we can successfully apply these rules to all its statements.

Rule get models how the information about which permissions are needed to access which variables is retrieved by IntentRepair, which, in turn, relies on the sender repair algorithm described above. Rule use indicates that, whenever a statement \(\textit{stmt}[v]\) accessing some variable v executes, the app must possess the necessary permission R(v). Rule sink deals with primitive \(\texttt{sink}\), which is secure only if the output channel’s security level q is not more restrictive than the permission R(w) required to access the sinked data w. The program can always safely terminate, without requiring any special permission (rule exit). Sanitizing a variable’s content may change (usually, reduce) the permission required to access it (rule sanitize). Conversely, successfully acquiring a permission extends the set of current permissions (rules no-/upgrade).

With this formalization, we can support our claim that IntentRepair patches such as Fig. 5b’s are information-flow safe by construction: Line 4 retrieves the required permission; Line 6 tries to acquire it, and terminates if this is not possible; Line 8 sanitizes the data, so that Line 9 is allowed to sink it.

3.2.7 Sanitize Operations

IntentRepair can be customized and extended by providing different kinds of implementation of the \(\texttt{sanitize}\) primitive that achieve a desired trade off between security preservation and app functionality. We distinguish between declassify operations, which reduce the precision of the data, and pure sanitize operations, which completely replace sensitive data with dummy values. The latter are straightforward to implement using default values or encryption. In contrast, declassify operations depend on the nature of the data that should be declassified. For example, location data can be declassified by replacing a precise location with an approximate one. Table 1 lists several declassify and sanitize operations implemented in IntentRepair.

Table 1. IntentRepair ’s declassification (top) and sanitization (bottom) operations on several kinds and types of sensitive data d.
Full size table

3.3 Implementation

We implemented our intent repair technique in a prototype tool also called IntentRepair. IntentRepair takes APK files or Java source code as input, which it analyzes as described above, and directly injects patches into the input files. IntentRepair is implemented in Java and comprises around three thousand lines of code. IntentRepair ’s static analysis uses the Wala framework [13] and APKTool [2] and works on the .dex and Smali intermediate representations. IntentRepair also uses Axplorer [7, 8] to detect sensitive sources based on an app’s permissions. IntentRepair ’s implementation includes a few workarounds to handle unsupported operations of the Android framework. For example, whether the user grants the extra permissions needed by a repair is stored dynamically as a Boolean flag. If the patch were to be deployed officially, the extra permissions could be added to an app’s manifest file.

4 Evaluation

We empirically evaluated the capabilities of IntentRepair in repairing information flow security bugs in Android apps. Our experiments answer the research questions:

RQ1:

How effective is IntentRepair? (“Effectiveness” refers to how many information flow security bugs IntentRepair can detect and repair.)

RQ2:

Is IntentRepair scalable? (“Scalability” refers to whether IntentRepair can be applied to realistic-size apps.)

All experiments described in this section ran on a MacBook with a 2.6 GHz 6-Core Intel Core i7 processor and 16 GB of RAM. For lack of space, we only present the main results and refer to the artifact package for details.

4.1 RQ1: Effectiveness of IntentRepair

4.1.1 Subjects

To assess IntentRepair ’s effectiveness, we selected apps from two widely used curated collections of open-source Android apps: DroidBench [1] and RepoDroid [21]. DroidBench was originally introduced to specifically benchmark taint analyses, whereas RepoDroid encompasses a broader selection of apps; both include a ground truth about which apps incur information-flow security leaks.

Starting from 45 apps (21 in DroidBench and 24 in RepoDroid), we selected all those that i) send sensitive information via implicit intents; or ii) receive information via implicit intents (regardless of whether they sink it or not). According to DroidBench’s and RepoDroid’s ground truths, only 14 apps (3 in DroidBench and 11 in RepoDroid) satisfy one or both these criteria; the selected apps are generally small, as each of them consists of only 50–100 lines of code over 2–3 classes. This is arguably due to the focus of DroidBench and RepoDroid, which were curated to mainly include apps that use (inter-app) communication mechanisms other than implicit intents. (RQ2 will demonstrate IntentRepair on a larger number of apps of realistic size.) Nevertheless, the 14 apps that we selected as experimental subjects do exhibit—in the small—significant patterns of information-flow exchanges. Figure 8 shows examples of code from some of these apps: Fig. 8a is a sender that sends out the IMEI device identifier to receivers that support action ; Figs. 8b and 8c are receivers supporting such action; Fig. 8b sinks this sensitive data, whereas Fig. 8c does not.

Table 2. IntentRepair ’s sender and receiver summaries of the 14 apps analyzed for RQ1. For each app and activity, the table reports the actions it receives and/or sends; the key used to store the data in the intent object; the value stored, and any permission needed to access the data. (Action is ; action is ; action is ; permission is ; is , is .)
Full size table

4.1.2 Sender/Receiver Analysis

Table 2 summarizes the outcome of IntentRepair ’s sender and receiver analysis on RQ1’s 14 experimental subjects.

IntentRepair found 23 activities that can receive intent objects with 5 different actions; and 11 activities that can send intent objects with 4 different actions. This determines 36 potential instances of sender-receiver communication between activities. For example, app sends an intent object that stores Android device ids under key ; this data can be received by the of the same app, as well as of the homonymous activity of apps , and . We also confirmed that IntentRepair detected all information-flow security leaks in DroidBench’s and RepoDroid’s ground truth.

4.1.3 Repair

Out of the 36 sender-receiver communication pairs, IntentRepair reported 17 instances where the receiver may inappropriately send the intent information to a public sink. In the previous example, this happens when the receiver is app . In all these cases, IntentRepair patched the sender-receiver pairs so as to avoid any information-flow security leaks. We manually validated these patches by running the communicating apps while monitoring the information sent to the sink, confirming that the leak occurs in the original app version (before applying the patch) and no longer occurs with IntentRepair ’s patch.

Fig. 8.
figure 8

Snippets of code from Android apps that send sensitive information via implicit intents.

Full size image

4.2 RQ2: Scalability of IntentRepair

Fig. 9.
figure 9

Statistics about which intent API methods are used more frequently in RQ2’s subjects.

Full size image

4.2.1 Subjects

To assess IntentRepair ’s scalability, we selected apps from the well-known app hosting platform FDroid [19]. To only consider realistic-size apps, we first selected all apps greater than 5 MB in size (1301 apps); out of them, we further selected all those that use implicit intents (855 apps) as our experimental subjects. Table 3’s left-hand half lists the five largest apps in this dataset, ranked by their size.

Table 3. The five largest apps among all RQ2’s 855 experimental subjects (left) and among the 59 of them that send sensitive data through implicit intents (right).
Full size table

Although the intent communication API is very rich, Fig. 9a shows that a small fraction of them dominate usage in our subjects. Two out of 25 methods to broadcast an intent object (abstracted by primitive \(\texttt{send}\) in \(\textsf{Tentative}\)) are used 80% of the time; alone covers 65% of usages. Similarly, method (out of all 30 methods to store data in an intent object) covers 40% of usages; integer values are stored in another 26% of usages.

4.2.2 Analysis and Repair

IntentRepair found 98 app modules (in 83 apps) that send sensitive data (location, file system, ...) through implicit intents; for 70 of them (in 59 apps), IntentRepair could also determine the 10 different intents’ actions:Footnote 7

figure bn

Table 3’s right-hand half lists the five largest apps among these 59 apps, ranked by their size. IntentRepair also found 98 app modules that match some of these 70 senders; and 23 sender-receiver pairs where information-flow security leaks may happen. It successfully produced patches for all of these (validated as in RQ1).

4.2.3 Scalability

In our experiments, IntentRepair ran for 10.5 s per app on average: this includes sender and receiver analysis (3.5 s), followed by sender-receiver matching and repair (7 s). This performance is reasonable for a prototype implementation, and shows that IntentRepair is also applicable to large apps.

4.3 Discussion

IntentRepair repairs information-flow leaks by simultaneously patching senders and receivers that may communicate; thus, applying the patches only to the receiving apps does not suffice in general. In an ideal scenario, one may equip a receiver with the information obtained by sender analysis, and use that information at runtime to identify the sender’s sensitive information (thus avoiding the need for patching the senders). Clearly, this would incur in all sorts of practical hurdles, as it is generally impossible to identify the sender apps with implicit intent communication.

Section 4’s empirical evaluation of IntentRepair demonstrated that it is applicable to realistic apps, and that it generates repairs that are effective at removing the source of information-flow leaks. While we informally inspected the patched apps, and tried them out by running them, to gain some confidence that they remain usable and their overall behavior consistent, we did not perform a rigorous analysis of usability. IntentRepair repairs senders by simply injecting permission information in their intent objects; since the size of this information is negligible, we are fairly confident that these changes do not have any meaningful impact on the sender app’s usability.

IntentRepair ’s repairs of receivers are potentially more invasive, as they may: i) request new permissions to the app user, and ii) terminate an activity to avoid an security leak. These actions are necessary, in general, to enforce information-flow security, but they may worsen the user experience. As we discussed elsewhere, IntentRepair ’s repair policies are customizable; thus, one may change it to achieve a different trade-off between usability and security (for example, by declassifying data instead of forcing app termination) depending on the practical application scenario.

5 Related Work

Previous work on automated repair of Android apps focused on bugs such as crashes, leaks, and configuration and compatibility issues. Tan et al. [23] describe how to repair null-pointer dereference crashes. Huang et al.’s technique [16] repairs inconsistent XML configuration files across Android versions. Zhao et al. [28] show how to generate fix templates for system- and device-compatibility issues. Guo et al. [15] detect and repair data losses that may occur when the user navigates from one UI component to another. Banerjee et al. [10] present a combined static and dynamic analysis technique to detect, validate, and repair energy bugs in Android apps. Xu et al. [27] tackle the problem of UI testing scripts becoming obsolete when an app’s design changes; to this end, they propose a technique that can identify and remove obsolete testing scripts. Bhatt and Furia [11] present a static analysis tool that can detect and repair Android resource leaks. Unlike all these works, the present paper targets information-flow leaks in apps in accordance with the Android permission model; it combines static and dynamic analyses to automatically detect and repair such leaks.

To our knowledge, this paper is the first that can automatically repair information-flow security issues that occur in intent communication. In contrast, many approaches [5, 6, 9, 12, 17, 18, 24, 26] have been proposed to detect information-flow violations; however, most of them focus on intra-app intent communication [5, 17, 18], whereas our IntentRepair fully supports inter-app detection (as we demonstrated in Sect. 4’s evaluation). The few previous approaches that can deal with inter-app communication have limitations—such as they only work on older Android versions [12, 26], or rely on third-party slicers [24]—that restrict their effectiveness on realistic apps. Following a general-purpose approach, Mesecan [20] is a repair tool for information-flow bugs that is language- and system-agnostic, as it is based on genetic algorithms. In contrast to their work, our IntentRepair is more specialized (on the Android permission model, and its intent-communication capabilities) and customizable, and is also capable of detecting information-flow bugs without requiring tests as input.

6 Conclusions and Future Work

In this paper, we presented IntentRepair: the first automated framework to detect and repair information flow leaks that may occur in Android when apps communicate using implicit intents. To address the key issue that senders and receivers communicating via implicit intents do not have a standard way of identifying the sensitivity of the data they are sharing, IntentRepair performs repair by injecting this information in the senders and processing it in the receivers, ensuring that their handling abides by the necessary permissions. We implemented IntentRepair in a prototype tool with the same name. In a preliminary evaluation involving 14 apps from the popular DroidBench and RepoDroid benchmarks, and 855 larger apps from the FDroid repository, IntentRepair showed promise, as it was able to precisely identify all known information flow security flaws in these apps, and to automatically fix them.

IntentRepair is flexible, in that users can decide how to balance enforcing security and preserving app functionality when they deploy automatically generated repairs. IntentRepair ’s analysis is also fine-grained, as it can identify different permissions for different pieces of data sent through intents. As future work, we’ll systematically evaluate how to implement common declassification patterns that are found in mature apps. Note that Android does offer an API to send intent objects only to receivers with certain permissions; however, this mechanism is coarse-grained and thus inapplicable to many scenarios of implicit intent communication—as we have seen in our experiments, where we found several apps that send data associated with different actions and permissions. In the future, our approach to enable privacy-compliant intent communication could be the basis for an official Android API, or perhaps be provided as an extension of the Android framework—for example, providing the capability of annotating any piece of data with the required permissions. Finally, a rigorous evaluation of IntentRepair ’s practical usability would also benefit from a user study.