In this paper, we perform a comprehensive study of 2,470 patched Android vulnerabilities that we collect from different data sources such as Android security bulletins, CVEDetails, Qualcomm Code Aurora, AOSP Git repository, and Linux Patchwork. In our data analysis, we focus on determining the affected layers, OS versions, severity levels, and common weakness enumerations (CWE) associated with the patched vulnerabilities. Further, we assess the timeline of each vulnerability, including discovery and patch dates. We find that (i) even though the number of patched vulnerabilities changes considerably from month to month, the relative number of patched vulnerabilities for each severity level remains stable over time, (ii) there is a significant delay in patching vulnerabilities that originate from the Linux community or concern Qualcomm components, even though Linux and Qualcomm provide and release their own patches earlier, (iii) different AOSP versions receive security updates for different periods of time, (iv) for 94 of patched Android vulnerabilities, the date of disclosure in public datasets is not before the patch release date, (v) there exist some inconsistencies among public vulnerability data sources, e.g., some CVE IDs are listed in Android Security bulletins with detailed information, but in CVEDetails they are listed as unknown, (vi) many patched vulnerabilities for newer Android versions likely also affect older versions that do not receive security patches due to end-of-life.
Most closely related to our work, Linares-V 'a @cite_91 conducted an empirical study based on the collection of 660 Android-related vulnerabilities mined from Android security bulletins, CVEDetails and XML feeds provided by NVD. They investigated three issues. First, they studied the CWE hierarchies and the types of vulnerabilities affecting Android. Second, they studied the Android layers affected by vulnerabilities. Third, they investigated the time intervals between the introduction date of the vulnerability and its fix date. Note that they mined the patched vulnerabilities up to November 2016. On the contrary, we collect 2,470 patched vulnerabilities in Android from August 2015 up to January 2019, which is more comprehensive. Moreover, our study not only covers all of their analysis with a more comprehensive dataset, but also studies new issues. These new investigations include, but are not limited to, the duration of security support for different versions and the delay in patching vulnerabilities originating from Linux and Qualcomm.
@cite_91
2398354233 2059610428 2766411424 1988036170
In this paper, we systematically study two vulnerabilities and their presence in existing Android applications (or “apps”). These two vulnerabilities are rooted in an unprotected Android component, i.e., content provider, inside vulnerable apps. Because of the lack of necessary access control enforcement, affected apps can be exploited to either passively disclose various types of private in-app data or inadvertently manipulate certain security-sensitive in-app settings or configurations that may subsequently cause serious system-wide side effects (e.g., blocking all incoming phone calls or SMS messages). To assess the prevalence of these two vulnerabilities, we analyze 62, 519 apps collected in February 2012 from various Android markets. Our results show that among these apps, 1, 279 (2.0 ) and 871 (1.4 ) of them are susceptible to these two vulnerabilities, respectively. In addition, we find that 435 (0.7 ) and 398 (0.6 ) of them are accessible from official Google Play and some of them are extremely popular with more than 10, 000, 000 installs. The presence of a large number of vulnerable apps in popular Android markets as well as the variety of private data for leaks and manipulation reflect the severity of these two vulnerabilities. To address them, we also explore and examine possible mitigation solutions. Component hijacking is a class of vulnerabilities commonly appearing in Android applications. When these vul- nerabilities are triggered by attackers, the vulnerable apps can exfiltrate sensitive information and compromise the data integrity on Android devices, on behalf of the attackers. It is often unrealis- tic to purely rely on developers to fix these vulnerabilities for two reasons: 1) it is a time-consuming process for the developers to confirm each vulnerability and release a patch for it; and 2) the developers may not be experienced enough to properly fix the problem. In this paper, we propose a technique for automatic patch generation. Given a vulnerable Android app (without source code) and a discovered component hijacking vulnerability, we automatically generate a patch to disable this vulnerability. We have implemented a prototype called AppSealer and evaluated its efficacy on apps with component hijacking vulnerabilities. Our evaluation on 16 real-world vulnerable Android apps demon- strates that the generated patches can effectively track and mitigate component hijacking vulnerabilities. Moreover, after going through a series of optimizations, the patch code only represents a small portion (15.9 on average) of the entire program. The runtime overhead introduced by AppSealer is also minimal, merely 2 on average. Given how the "patching treadmill" plays a central role for enabling sites to counter emergent security concerns, it behooves the security community to understand the patch development process and characteristics of the resulting fixes. Illumination of the nature of security patch development can inform us of shortcomings in existing remediation processes and provide insights for improving current practices. In this work we conduct a large-scale empirical study of security patches, investigating more than 4,000 bug fixes for over 3,000 vulnerabilities that affected a diverse set of 682 open-source software projects. For our analysis we draw upon the National Vulnerability Database, information scraped from relevant external references, affected software repositories, and their associated security fixes. Leveraging this diverse set of information, we conduct an analysis of various aspects of the patch development life cycle, including investigation into the duration of impact a vulnerability has on a code base, the timeliness of patch development, and the degree to which developers produce safe and reliable fixes. We then characterize the nature of security fixes in comparison to other non-security bug fixes, exploring the complexity of different types of patches and their impact on code bases. Among our findings we identify that: security patches have a lower footprint in code bases than non-security bug patches; a third of all security issues were introduced more than 3 years prior to remediation; attackers who monitor open-source repositories can often get a jump of weeks to months on targeting not-yet-patched systems prior to any public disclosure and patch distribution; nearly 5 of security fixes negatively impacted the associated software; and 7 failed to completely remedy the security hole they targeted. An enormous number of apps have been developed for Android in recent years, making it one of the most popular mobile operating systems. However, the quality of the booming apps can be a concern [4]. Poorly engineered apps may contain security vulnerabilities that can severally undermine users' security and privacy. In this paper, we study a general category of vulnerabilities found in Android apps, namely the component hijacking vulnerabilities. Several types of previously reported app vulnerabilities, such as permission leakage, unauthorized data access, intent spoofing, and etc., belong to this category. We propose CHEX, a static analysis method to automatically vet Android apps for component hijacking vulnerabilities. Modeling these vulnerabilities from a data-flow analysis perspective, CHEX analyzes Android apps and detects possible hijack-enabling flows by conducting low-overhead reachability tests on customized system dependence graphs. To tackle analysis challenges imposed by Android's special programming paradigm, we employ a novel technique to discover component entry points in their completeness and introduce app splitting to model the asynchronous executions of multiple entry points in an app. We prototyped CHEX based on Dalysis, a generic static analysis framework that we built to support many types of analysis on Android app bytecode. We evaluated CHEX with 5,486 real Android apps and found 254 potential component hijacking vulnerabilities. The median execution time of CHEX on an app is 37.02 seconds, which is fast enough to be used in very high volume app vetting and testing scenarios.