Inter-app communication in Android

Abstract

The Android platform is designed to support mutually untrusted third-party apps, which run as isolated processes but may interact via platform-controlled mechanisms, called Intents. Interactions among third-party apps are intended and can contribute to a rich user experience, for example, the ability to share pictures from one app with another. The Android platform presents an interesting point in a design space of module systems that is biased toward isolation, extensibility, and untrusted contributions. The Intent mechanism essentially provides message channels among modules, in which the set of message types is extensible. However, the module system has design limitations including the lack of consistent mechanisms to document message types, very limited checking that a message conforms to its specifications, the inability to explicitly declare dependencies on other modules, and the lack of checks for backward compatibility as message types evolve over time. In order to understand the degree to which these design limitations result in real issues, we studied a broad corpus of apps and cross-validated our results against app documentation and Android support forums. Our findings suggest that design limitations do indeed cause development problems. Based on our results, we outline further research questions and propose possible mitigation strategies.

An Empirical Study on Android-Related Vulnerabilities

“…Researchers have also contributed to improve the security of the Android ecosystem by analyzing security vulnerabilities and proposing improvements to current security models [12], [16], [17], [22], [25]- [32], [32]- [35]; however, while the focus of the academic research has been the security of the applicationsthe closest component to the user-, the core of the Android ecosystem (i.e., the Android OS) has received little attention.…”

“…1) Security in Android Applications: Android malware and vulnerabilities in Android apps are characterized by a novel set of flaws that exploit user level weaknesses and the issues in security mechanisms of the Android OS. For instance, Androidspecific attacks include (i) privileges/permissions escalation through pairs of infected apps that exploit inter-application communication or misconfigured apps [10]- [12], [35], [36], (ii) applications tapjacking/hijacking by apps repackaging and substitution [26], (iii) information leaking through covert channels [37], [38], (iv) SSL vulnerabilities in hybrid [33] and native apps [32], (v) security issues introduced by third party libraries [34], and (vi) security issues introduced by OS customizations [28]. These novel attacks, in addition to classic security attacks induced by malware (e.g., DoS), have been widely studied by the community and several approaches have been proposed for their detection and mitigation, such as TaintDroid [39], COVERT [10], [11], FlowDroid [40], MudFlow [41], Chabada [42], Q-Floid [43], and AppInspector [44].…”

“…As a contribution from the research community, substantial effort has been recently invested in the analysis and detection of malware and vulnerabilities at the applications level (see e.g., [10]- [12]). However, (i) few works have focused on the vulnerabilities at the OS level [13]- [17], the underlying platform on which any app runs, and (ii) most of the studies have just focused on a limited number of vulnerabilities.…”

Security code smells in Android ICC

“…In addition to securing the ICC-based communication, Shekhar et al proposed a separation of concerns to reduce the susceptibility for manipulation of Android apps, by explicitly restricting advertising frameworks [21]. Ahmad et al elaborated on problematic ICC design decisions on Android, and found that missing consistent message types and conformance checking, unpredictable message interactions, and a lack of coherent versioning could break inter-app communication and pose a severe risk [4]. They recommend a centralized message-type repository that immediately provides feedback to developers through the IDE.…”

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

“…The digital forensic used in criminal investigation and evidence, for example, is unproven and is highly criticised in legal proceedings [4]. Such non-rigorous specifications can cause interpretation issues, most commonly developers often choosing undocumented practices that can lead to applications vulnerable to security and privacy threats [1]. A typical consequence of misinterpreting the informal documentation may lead to a scenario where an application developer may incautiously expose a component to third party applications [23].…”