CrashSafe: a formal model for proving crash-safety of Android applications

Android application framework and components

Android application framework allows developers to build innovative applications for mobile devices using programming languages Koltlin, C++ and Java [18]. The Android SDK tools compile the application source code into an Android application package (APK) containing all the contents of Android application which is then used by Android-powered devices to install the application. Android operating system treats each application as a different user and assigns each of them a unique user ID. Each application is executed in isolation by a separate process using its own virtual machine. By default, Android implements the principle of least privilege, where each application is given permission only to access components required for its work and no more [17]. Applications with the same user ID (e.g., by sharing the same Linux user ID) can share data with each other and can run in the same process.

Intents

Android is a Linux-based operating system where each application is assigned a unique user ID and is run in an isolated virtual machine to provide better application management and security [37]. To work as a single entity for better user experience, Android applications uses intents, mediated by Android runtime, to share data and services with each other. This sharing can be inter-application (a component of one application communicate with a component of another) or intra-application (among components within an application). One component sends an intent including optional name of target component, name of action to be performed, data to operate on and category. The receiving component, likewise, include intent filter with specification of intents that it is interested to receive.

An action is a string that specifies the action to be performed (e.g., VIEW) or has happened and is reported (e.g., BATTERY_LOW). In addition, intent includes a (possibly empty) list of categories, each contains additional information about the component that should handle the intent. The data field of the intent include a uniform resource identifier (URI) to identify the data to act upon and the multi-purpose internet mail extensions (MIME) data type. The type of the data can be inferred from the data itself, though, it is important to add the type of data as it helps Android system to locate the most appropriate component for the intent. The intent fields just described are sufficient for the system to identify a relevant component it should start to receive the intent and hence are included in the formal definitions (“Formalizing inter‑component communication” section). There are additional fields to carry extra information as key-value pairs and flags to carry metadata, however, none of them affects the way an intent is resolved to a component.

Based on the way a set of target components are identified, intents are categorized as explicit and implicit. In an explicit intent, a component is addressed explicitly using a fully-qualified name and are normally used in an application to communicate with its own components as they are known to the owner. For explicit intent, the mechanism to find an appropriate component for an action is straight forward: the component is described by a full-qualified name inside the intent which the system can easily locate. On the other hand, in an implicit intent, a component is addressed using other fields action, data (URI and MIME type) and category. As a running example to understand intents and intent filters, consider an Email and a Browser application are installed on Android device. The Email application displays an email message, having a hyperlink to a web page, in an activity. When the user clicks on the link in the message displayed to the user by the activity of the Email application, the activity sends an intent to Android system for opening (viewing) the requested web page by the browser.

An implicit intent exampleIntent is created as an object of Intent class using the new constructor as shown in Listing 1. The target component name is not provided anywhere which makes the intent created implicit. The values for the fields action, category, data URI and data (MIME) type are added using methods setAction(), addCategory(), setData() and setType(), respectively on lines 3–7. The next function startActivity() on line 8 starts an activity for the desired action and provides the intent exampleIntent including other necessary data. The implicit intent in Listing 1 can be made explicit just by replacing the code on line 2 with Intent exampleIntent = new Intent(this, exampleActivity.class));. This code adds the name of target activity exampleActivity explicitly to the intent created.

Inter-component communication

For an application to communicate with another application, a component of the first application creates and sends an intent to a component of the target application, as shown in Fig. 2. The component A wants component B to perform some action on its data of a particular category. To do this, it creates an intent with name of action, data and its category and sends it to B, which performs the requested action on the data.

Communication based on intents can be with or without the target component name in intent. If a target name is included in the intent (explicit intent), Android system passes on the intent to the target component. Inter-component communication using explicit intent is straight forward and is not included in this work. To address a component using an intent without the target component name (implicit intent), a general action is declared and the target is resolved by the Android system (runtime). The type of action in implicit intent, to be performed by a component, enables the system to find a set of appropriate components for that action. Finding the target component for an implicit intent is complicated: the system takes the intent’s data and looks for an appropriate set of components in the applications available on the mobile device. In case only one appropriate component is found, the system start that component, however, for more options, the system asks the user using a dialogue to choose from the list.

When a component intends to start another component using implicit intent (see example below), it sends an intent and the system looks for appropriate components by looking into the intent content (action) and comparing with intent filters declared in applications on the device. Android enforces this mechanism using intent filters (Listing 2) declared in a manifest file: application specifies the type of intents in its manifest file it should receive. For the Browser application to receive the intent created by the Email application (Listing 1), the Browser must have the filter as defined in Listing 2. This filter declares an action ACTION_VIEW, categories DEFAULT and BROWSABLE and data URL and type text/hmtl for an activity to display the web page in a tab. When the Browser application receives this intent, it is checked against the filter and as it can deliver the requested service (see proof of this in “Proofs” section), an activity of the Browser opens the web page from the URL provided in a tab. Declaring an intent filter for a component enable other applications to start it. A component, with no intent filter declared in manifest file, can only be started by an explicit intent.

The inter-component communication between two components in Fig. 2 appears a direct communication between two components A and B, but in fact it is mediated by the Android system as shown in Fig. 3. The Email application in our running example communicates with a different application to display a web page in response to the user click on a hyperlink received in the email opened by an activity of the Email application. Let assume, there exists application Browser that can better serve Email, but the latter does not know if the former exists or can perform the desired action. For this operation, the activity A of Email starts implicitly the activity B of Browser without mentioning the name of target as the following: (1) activity A creates the intent (in Listing 1) with action ACTION_VIEW it wants to be performed and passes it by calling the method startActivity(). (2) The Android system receives the intent sent by A and looks for a relevant component among components of applications currently installed on the device. Let assume it matches (the filter in Listing 2 of) activity B in application Browser. (3) Android system activates B by calling its method onCreate with the intent received from A and as result, the Browser application displays the requested web page in a tab. This sequence of events appears to the user from a single application (Email) but in-fact it is rendered by two different applications namely Email and Browser. This all happens seamlessly to the user using ICC.

Even though, ICC is the major mechanism for inter-application interactions and contributes to rich user experience of mobile computing, but there are design limitations [1] in it and is one of the favourite targets to security threats [7, 40]. In the next section, formal definitions of intents, intent filters and inter-component communication are described and used in the formal reasoning about inter-component communication.

Syntax of intent and intent filter

The main components of Android ICC are the data structures intent, intent filter and matching functions. An intent represents the content and the requested operation while the filter models a component. The data structures intent and intent filters are formalized in this sub-section and the matching functions are formalized in the next sub-section.

An implicit intent is a simple data structure containing the address and type of the data to act upon, the action to perform on data and some additional information. An intent is inductively defined in Coq as shown in Listing 3. The inductive definition consists of only one constructor (int, line 2) to construct elements (intents) of type intent. The constructor take as arguments an action, list of categories, URI and MIME type of the data. All the names (such as actions, categories, schemes, hosts and MIME types) are represented using the type atom defined in the library Atom, edited from [5]. The third argument of intent of type uri represents the content URI and is defined in Listing 4. A URI include optional elements scheme, host, port and path, represented by the arguments on lines 3, 4, 5 and 6, respectively. All the URI elements have type atom except port (line 5) which is modelled as a natural.

To map an intent to a component, the elements of an intent are matched against the elements in the intent filter of a component defined in the manifest file of Android application. Intent filter filter is inductively defined in Listing 5. The only constructor filt of type filter gets four arguments: list of actions, list of categories, list of content URIs and MIME types (lines 3, 4, 5 and 6, respectively). The definitions of intent and intent filters are used to define Android application (line 1, Listing 6) at a high level modelled as a list of intents that it may invoke to integrate with other applications on the device. The mobile device environment (line 2, Listing 6) is the list of applications on the mobile device, represented by the list of filters in all the applications installed.

Encoding Android application and environment

To demonstrate the applicability of our formal developments, a simple Android application and mobile device environment is created using formal notations defined. For simplicity, we assume the application consists of a single intent and the device contains a single application with just one intent filter. To realize this scenario, the intent and intent filter from Listings 1 and 2 are encoded in the formal notations developed in “Syntax of intent and intent filter” section. The encoding is used in a formal proof in next section.

The intent ingredients including the action ACTION_VIEW, two categories CATEGORY_DEFAULT and CATEGORY_BROWSABLE, data type text_html and elements (scheme, host, port and path) of data URL are defined of type atom in Listing 7 (lines 5–7). The URL of the web page (line 1, Listing 1) is defined on lines 8–9 with scheme, host, port number and path. All these parameters just defined are used to define intent and filter from Listings 1 and 2, respectively. In other words, the Coq definitions exampleintent and examplefilter of intent and filter (Listing 8) are the formal representations of the corresponding Java definitions in Listings 1 and 2. The implicit intent exampleintent is defined with action ACTION_VIEW, list of categories including CATEGORY_DEFAULT and CATEGORY_BROWSABLE, data URL and MIME type text_html. Similarly, the filter (for the Browser activity) is defined with a list of actions that it can perform, data categories, data URLs and types.

Finally, the example intent is used to define the application exampleapp (representing Email) and the filter is used to define the device environment exampleenv. The exampleenv represents the only application Browser on the device with one filter examplefilter. The major advantage of such formal definitions is that they can be used to mathematically reason about Android applications as demonstrated in “Proofs” section.

Intent resolution

After Android system receives an intent, it starts the appropriate target component for the intent based on the result of three tests [24] for action, category and data, respectively, against the corresponding elements in the intent filter of the target component. For an intent to resolve to a component, it must pass all these three tests. If the intent can not be resolved to any component, the source application may crash [17]. Following are the formal definitions of these three tests.

The action test is simple: the action in intent is matched against actions in the filter. This is modelled by the function testaction defined using the keyword Definition in Listing 9. The function definition in turn is using another function find which searches the action of type atom in intent (first argument) in the list of actions in filter (second argument). The space holder _ is used to represent arguments whose values are not important in the function body. The category test compares all the categories in the intent with the categories in the filter. The recursive function testcategory (Listing 10) takes a list of categories (of type atom) and categories listed in the intent filter and checks if all the categories in intent exist in the filter.

The third test, defined as a recursive function testdata in Listing 11, checks if the URI and MIME type of the content in the intent exist in the list of URIs and MIME types in the intent filter. Based on whether or not the URI and/or MIME type exists in the intent and/or filter, there are five different results. The first four cases in the function body (lines 4–10) correspond to the four rules on Android developers’ website [19]. These (informal) rules are (formally) implemented using pattern matching on the four arguments namely, intent URI (iuri), intent type (itype), list of URIs in filter (filuris) and list of MIME types in filter (filtypes).

The first rule states that an intent with no URI and no MIME type passes the test if there are no URI and MIME types listed in the filter. This is represented on the line 4 where values of all the four arguments are None (option type) or nil (list). The second case (line 5) models rule b in the documentation, which states that an intent with a URI but no MIME type can be accepted only if its URI matches a URI pattern in the filter and the MIME type specification list is empty. The rule c is represented by the case 3 (line 7). An intent with only MIME type can pass the test if the same type exists in the list of types in the filter and there is no URI specification in the filter. The fourth rule is modelled by the case 4 (lines 8–10). An intent with URI and MIME type is accepted only if both, the URI and MIME type, matches with URI and MIME type in the filter. In all other cases, such as | None, None, cons u’ ul, cons t’ tl \(\Rightarrow\) false, implicitly included in the code using space holders on line 11, the test fails.

The function testdata is calling two other functions testtype and testuri (lines 6, 7 and 9, Listing 11). For the first rule of function testdata, there is no URI and no MIME type and the result is true. For the next three rules, however, at least one of the URI and MIME type exists and the corresponding test function(s) is/are called. The test function testtype (Listing 12) is simple: it searches intent type in the list of filter types. If there is no intent type and likewise the filter does not require one (list of types in filter is empty), the test is passed. The formalization include explicit types and does not model implicit types. In the later case, the type would be inferred from the URI.

The definition of testuri is shown in Listing 13. It gets the list of filter URIs and the intent URI as arguments and compares the intent URI to a URI specification in the filter by comparing it only to the parts of URI included in the filter. In the first case, no URI in the intent, test is passed. The next six cases (lines 4–25) models the text If a scheme is not specified \(\dots\) authority, and path pass the filter. in the official documentation [19]. The last case (lines 26–31) represents the tests for all other cases: the axillary function cmpoattr compares the optional filter URI attribute with an intent URI attribute. For the attribute test to pass, the intent must include the same attribute listed in the filter and for the URI test to pass, all the attributes must pass the attribute test.

Finally, all the tests are combined together in function resolve defined in Listing 14. This function gets an intent and a filter and returns true if all the tests, namely testaction, testcategory and testdata, are passed. In other words, given an intent and a filter, the formal developments enable one to check if an intent would resolve to (accepted by) a component.

Application crash-safety

After intent, intent filter and intent resolution are defined, Android applications’ safety against crashes due to intents is formally defined. The definition resolve is used to formally describe crash-safety property intent_crash_safety of an intent (Listing 15). This property is too strong: it defines an intent is crash safe if it must be accepted by the filter. To define crash-safety of an intent with respect to the entire device, a recursive function intent_crash_safetey_env is defined in Listing 16. An intent is crash-safe in the device if there exists at least an application (filter) that accepts the intent.

Finally, a crash-safe application is defined in Listing 17. An application (represented by the intents it may invoke) is crash-safe if every intent it may invoke resolves to an application component (represented by a filter) on the device. In the next section (“4” section), we formally prove that the example Android application with invoked intent exampleintent does not crash in the context of another application examplefilter on the device.

Proof of application crash-safety

When an application invokes an intent, there must be an application on the mobile device to handle the intent, otherwise, the application that invoked the intent will crash [20]. Android platform ‘guarantees’ an intent must resolve to an application. The existing enforcement mechanism is to test, there exists an activity to respond to the invoked intent, when the source application activity first starts. The Java code to perform such a test is listed in Listing 18. The value of the boolean variable isIntentSafe determines if invoking the intent is safe for the application. Such tests are performed dynamically at run time after the application is deployed which is too late to avoid bad user experience. Furthermore, there is no proof of guarantee of robustness of the test and hence no proof of guarantee of application crash safety. In this section, we formally prove for the Email application whether or not the intent it generates resolves to the application Browser. It follows the proof of crash-safety of the application built from the example intent (by the Email app) in the environment created from the example filter (by the Browser app).

For the first proof, a general proof of intent resolution is carried (theorem resolve_intent, Listing 19) which is used in the proof of resolution of our example intent exampleintent to filter examplefilter from Listing 8 (theorem exampleintent_res_to_examplefilter, Listing 20). Theorem resolve_intent defined in Listing 19 states that given an intent and a filter, if the intent passes action, category and data tests, it will be accepted by the application component with the filter defined in its manifest file. Note that the intent is constructed using the intent fields (the arguments of constructor int in Listing 3). This theorem is proved by first unfolding the definition of function resolve (using tactic unfold) and then using rewriting and simplification by Coq commands (tactics) rewrite and simpl, respectively. The proof of this theorem begins with keyword Proof at line 6 and ends at line 13. The last tactic Qed adds the proof to internal database for later retrieval in other proofs (see proof in Listing 20 for an example).

The proof of theorem exampleintent_res_to_examplefilter in Listing 20 formally verifies that the intent exampleintent resolves to filter examplefilter. This theorem is proved by first unfolding the definition of intent_crash_safety and then applying the theorem resolve_intent. This opens up three sub-goals which are closed by case analysis on the definition of equality using tactic destruct and rewriting an axillary lemma eq_dec_atom_same (see source code [24] for all definitions and proofs).

Finally, the example application Email modelled as exampleapp from Listing 8 is proved crash-safe in the device environment exampleenv with one application Browser modelled as examplefilter in Listing 8. The theorem exampleapp_is_crash_safe_app (Listing 21) states that the Email application can safely invokes the intent for opening a URL in a browser tab by requesting the Browser application installed on the mobile device.

Proof of broadcast resolution

A broadcast is a message wrapped in an intent and is received by any application that has declared a broadcast receiver, most commonly, in its manifest file. The method sendBroadcast(intent) is used to send a broadcast intent to multiple receivers. Using the developed formal setting, a formal proof that a broadcast message is indeed received by the applications subscribed for it (by declaring a receiver), is carried in Coq theorem prover.

To do this, first a broadcast message (intent) is precisely defined in Listing 22. A broadcast intent is accepted (resolved to) by every application inside Android device environment that has declared a receiver for it. For simplicity, we assume every application on the mobile device (system) has declared broadcast receiver. This concept is formalized using recursive function broadcast in Listing 22. It takes an intent and system environment (list of applications’ filters) and returns true if the intent is accepted by every application on the device.

Theorem 4 (Listing 23) states if an intent in a system is broadcast, it must resolve to (accepted by) every application on the system. This theorem is proved using rewriting, unfolding the definitions of function broadcast and then using case analysis on the boolean argument of andb. This later would generate two sub-goals: the first one is easy and is closed using tactic auto and the second one is closed using inversion. In addition to tactics used in earlier proofs, this proof is using an axillary lemma broadcast_append, tactics In_split and inversion.

Robust environment extension

Given a mobile environment and an application, it was formally verified in “Proof of application crash-safety” section that the application is safe in the environment. With the passage of time, it is normal for the user to install more applications and/or extend the intent filters of existing ones. It is necessary to ensure such an extension does not invalidate the guarantee previously provided. To further highlight the usefulness of our formal framework, we carry formal proof of application safety (Listing 24) and then prove that extending the filter with more categories is safe (Listing 25).

The Coq script in Listing 24 defines a general URL, intent and a filter. The theorem aninttent_resoves_to_filter formally proves that the intent resolves to (be accepted) by the components with filter afilter. In Listing 25, it is checked that the same intent also resolves to an extended (with categories cats) intent filter afilterplus. In other words, the proof of theorem aninttent_resoves_to_filterplus in Listing 25 confirms that if further categories are added to a filter, the application sending the intent is still safe and will not crash. Note that, variables a, c, p, s, h, cats used in definitions in Listings 24, 25 range over any action, category, path, scheme, host and categories, it generalizes the scope of the formal guarantees to any application and system.

Evaluation of the formal model

Demonstrating the usability of formal definitions of intent, filter and ICC, the proofs given in Listings 20, 21, 23, 24 and 25 statically (before executing them) guarantees that the applications invoking the intent will never fail given the conditions. These conditions are formally stated on lines 2–3 for the last theorem in Listing 23. For the theorems in Listings 20 and 21, there is no condition (hypothesis) and the proofs are guaranteed for the specific example intent and filter. The major advantage of proofs carried in mechanical theorem prover Coq is that the proof scripts are rigorous and their correctness can be checked using computer.

Formal modelling and proofs using interactive theorem prover, such as Coq, are more expressive and powerful than conventional simulation and formal proofs using model checking [10]. Simulation and model checking based approaches can be used to prove functional properties, however, they cannot be used to guarantee safety and security properties or can prove but with limited scope. Formal methods based on interactive theorem proving overcomes the disadvantages (e.g., state explosion problem) of model checking [3]. As the formal model CrashSafe has been defined in interactive theorem prover Coq, the formal developments and proofs are rigorous, reliable, have wide spread scope and can be mechanically checked. It can be used to prove safety properties of Android applications and can serve as a formal specification of Android ICC. The formal model, for example, can be applied to mathematically prove the shift of JavaScript process from a browser application on to a cloud-based computer for better performance [25] preserves the intended functionality.

Application crashes due to ICC

The most relevant research work is the study of Android applications crashes due to ICC. Ye et al. built an automated testing tool DroidFuzzer [41] to find bugs in Android applications. The tool, tailored towards activity components of applications, creates (crash) logs of abnormal data based on the data types (video and audio) a target component can accept as described in its intent filter. The tool was evaluated against three applications, two music players and one browser, using Android emulator and found 14 bugs. DroidFuzzer is limited only to activity component of Android applications and addresses applications crashes caused by the type of data. The formal analysis in this paper, on the other hand, studies crashes in any type of application component caused by any parameter of the intent (including data type, URL, action and category). A similar tool, intent fuzzer [35], was built for fuzzing inter-component communication in Android. Similar to DroidFuzzer, intent fuzzer generates a set of empty intents that a component can receive based on action and data type parameters. Inter fuzzer is rich in terms of coverage as it considers action, in addition to data type considered in DroidFuzzer. The most recently developed tool is CrashScope [30]. CrashScope automatically test Android applications using a systematic input generation based on several static and dynamic strategies and generates detailed crash reports in natural language formate. Another tool VanarSena [33] was developed for reporting crashes in applications by dynamically analysing applications’ behaviour at runtime. The tool has been extensively tested against 3000 applications and found 2969 bugs. As VanarSena has been developed for and tested against Windows applications, we consider it orthogonal to our work.

The first fundamental difference between these tools and the work in this paper is that the former find bugs in applications using their data receiving capabilities (by generating several input pattens) while our work checks if an application crashes based on the receiving capabilities of other applications. The second difference is that these tools creates set of intents from the given data using mutation while our work generalizes on all possible intents using universal quantification. The third, and the most important, difference is that the approaches described do not have formal foundation and hence can be used to detect presence of failures/crashes but the formal model built in Coq can be used to prove absence of crashes in applications, the later being more power full approach.

Tools and frameworks for ICC analysis

Amandroid [40] is a framework that is tailored for Android applications to analyse their inter-component data flow. It captures both control and data flows by building a precise flow and context-sensitive inter-component data flow graph for application. The graph includes ICC edges and data and control can flow through these edges. A flow and context-sensitive algorithm is used to match the inter-component call source to the target. The flows are tracked by first inferring parameters for Android API calls for ICC, then resolve to the target (implicit or explicit) component(s) and track the flow from the source to target. There are other tools such as JarJarBinks [28] used to find bugs and study robustness of ICC in Android applications.

Chin et al. provided a tool ComDroid [9] for Android applications analysis. They analysed Davlik bytecode and detected vulnerabilities in inter-application communication of Android. Based on static analysis, ComDroid can detect a range of vulnerabilities including intent spoofing, broadcast theft, activity and service hijacking. Bugliesi et al. [7] developed a formal framework for the analysis of ICC. Their framework is based on typing techniques and include a formal calculus to reason about ICC. They implemented a prototype called Lintent that performs security type checking for Android applications.

Methods and techniques for ICC analysis

Later on, inspired from ComDroid [9], Octeau et al. [31] adopted a more general approach and developed a solver using a declarative language COAL. Using COAL, the inter-component objects are modelled and the required values of objects are inferred by taking the correlation between object fields. Even though, the solver applied to Android, it can be used in general static program analysis, in particular, where values of objects need to be inferred. Li et al. proposed a static taint analyser IccTA [26] for detecting leaks in ICC by tainting data. IccTA work on Dalvik bytecode and can detect inter-component based privacy leaks by providing a control-flow graph.

Addressing ICC as an instance of interprocedural distributive environment, Octeau et al. [32] developed a static analysis technique. In their approach, a specification is identified for every source and target of the ICC. The specification include values such as component name, action, category and data type and infers the missing values. By using [32], an analysis tool Epicc has been developed and more than a thousand applications were analysed for ICC vulnerabilities. Epicc analyses retargeted Java bytecode and does not handle URIs and content providers.

The state-of-the-art research work addresses Android security in terms of information leaks [26, 40] through ICC or finds bugs and vulnerabilities in ICC [7, 9, 28, 32]. On the contrary, CrashSafe checks application’s safety against crashes caused by ICC. The tools DroidFuzzer [41], intent fuzzer [35], CrashScope [30] and VanarSena [33] investigate Applications’ safety against crashes caused by ICC, however, their results can not be formally guaranteed. Furthermore, they are limited only to activities of applications [41], lack support for Android applications [33], or addresses applications’ failures based on their own receiving capabilities. CrashSafe, on the other hand, has a formal foundation which makes it more rigorous, powerful and allows one to mathematically reason about all components of applications.