An Empirical Study on Android-related Vulnerabilities
Mario Linares-Vasquez, Gabriele Bavota, Camilo Escobar-Velasquez
AAn Empirical Study onAndroid-related Vulnerabilities
Mario Linares-Vásquez , Gabriele Bavota , Camilo Escobar-Velásquez Systems and Computing Engineering Department, Universidad de los Andes, Bogotá, Colombia Faculty of Informatics, Universita della Svizzera Italiana, Lugano, [email protected], [email protected], [email protected]
Abstract —Mobile devices are used more and more in everydaylife. They are our cameras, wallets, and keys. Basically, theyembed most of our private information in our pocket. For thisand other reasons, mobile devices, and in particular the softwarethat runs on them, are considered first-class citizens in thesoftware-vulnerabilities landscape. Several studies investigatedthe software-vulnerabilities phenomenon in the context of mobileapps and, more in general, mobile devices. Most of these studiesfocused on vulnerabilities that could affect mobile apps, while justfew investigated vulnerabilities affecting the underlying platformon which mobile apps run: the Operating System (OS). Also,these studies have been run on a very limited set of vulnerabilities.In this paper we present the largest study at date investigatingAndroid-related vulnerabilities, with a specific focus on theones affecting the Android OS. In particular, we (i) define adetailed taxonomy of the types of Android-related vulnerability;(ii) investigate the layers and subsystems from the Android OSaffected by vulnerabilities; and (iii) study the survivability ofvulnerabilities ( i.e., the number of days between the vulnerabilityintroduction and its fixing). Our findings could help OS and appsdevelopers in focusing their verification & validation activities,and researchers in building vulnerability detection tools tailoredfor the mobile world.
I. I
NTRODUCTION
In the last few years, mobile apps have powered a wholenew economy that substantially impacted the software market.The cultural popularity of mobile devices, the new monetiza-tion/revenue models the apps’ market propose, and the capillarydistribution infrastructure represented by app stores, are onlysome of the driving factors making apps an attractive marketfor software developers. Also, the need for “enterprise apps"that support startups or serve as a new front-end for traditionalcompanies is pushing software-related professionals to embracethe mobile technologies [1].From the users’ perspective, mobile apps and devices are amechanism for achieving ubiquity, allowing them to performmultiple tasks and daily activities from anywhere, and to alwayshave available at the touch of their hands important/sensitiveinformation. Consequently, the security of mobile apps and ofthe underlying platforms on which they run has become a bigconcern for researchers and practitioners, due to the impact thatsecurity issues affecting mobile platforms might have on theprivate life of individuals ( e.g., allowing to stole private files)as well as on companies ( e.g., allowing to intercept strategicbusiness decisions) [2]–[4]. Recently, the impact of those vulnerabilities in everyday lifehas been more evident to the society due to public announce-ments of malware and vulnerabilities in mobile platformsthat compromise sensitive information and/or computationalresources in the affected devices. In 2015 mobile malwarereached a tremendous +153% (Android) and +235% (iOS) inthe number of reported threats as compared to the previousyear [4]. Representative examples of mobile malware withnotorious impact are games such as “Cowboy adventure"and “Jump chess" that infected about 1 million devices [5],the Locker trojan [3], [4] for Android, and the XcodeGhostmalware that infected 40K+ apps from the Apple App Store[4]. Also, according to the CVE details portal [6], 125 and 523vulnerabilities in the Android OS were reported in 2015, and2016, respectively. One of those vulnerabilities is “Stagefright"[7]–[9] that compromised 95% of the Android devices in 2015.As a contribution from the research community, substantialeffort has been recently invested in the analysis and detectionof malware and vulnerabilities at the applications level (see e.g., [10]–[12]). However, (i) few works have focused onthe vulnerabilities at the OS level [13]–[17], the underlyingplatform on which any app runs, and (ii) most of the studieshave just focused on a limited number of vulnerabilities.In this paper, we present an empirical study aimed atanalyzing from several different perspectives Android-relatedvulnerabilities, with a specific focus on those affecting theAndroid OS. In particular, we study (i) the types of vulnerability,(ii) the layers and subsystems from the Android OS affected byvulnerabilities, and (iii) the survivability of vulnerabilities ( i.e., the number of days between the vulnerability introduction andits fixing). While previous studies have focused the attentionon a small set of vulnerabilities ( e.g.,
11 in [14], 1 in [13], and32 in [15]), we mined all the vulnerabilities (660) available inthe official Android bulletins and the CVE-details portal up toNovember 2016. The vast majority of our study has been carriedout via manual analysis of vulnerability-related documentsavailable on issue trackers, versioning system, official Androidsecurity bulletins, and information available on the NationalVulnerability Database [18].Knowing the types of security vulnerabilities affecting theAndroid devices and their characteristics can help to guide (i)apps developers, in focusing their verification & validationactivities toward the identification of the most frequentlyreported types of vulnerability, (ii) researchers, in investing a r X i v : . [ c s . S E ] A p r n vulnerabilities detection tools targeting the most diffusedtypes of Android-related vulnerabilities (thus being particularlyvaluable to increase the security of Android devices), and (iii)language/API developers, to design/improve mechanisms forsecure coding of Android apps and the underlying platform.As a result of our study we defined a detailed taxonomyof vulnerabilities affecting Android devices (Fig. 2) based onthe Common Weaknesses Enumeration [50], and identifiedthe layers/subsystems of the Android OS mostly impacted byvulnerabilities (Fig. 4). We found that the hardware drivers inthe lowest level of the Android OS stack ( i.e., , linux kernel),and the native libraries are the layers mostly impacted bysecurity vulnerabilities, and the lack of secure coding practicesfor restricting operations in the bounds of memory buffers isthe main source of vulnerabilities. In addition, we found thatAndroid-related security vulnerabilities survive for very longtime (at least 724 days, on average).II. B ACKGROUND AND R ELATED W ORK
The Android OS is an open source mobile OS developedby Google and based on the Linux Kernel. It is composedof a set of architectural layers that follows a software stackmodel, having the Linux Kernel as the foundation, and anApplications layer as the closest interaction point for theend users. Each layer is composed of subsystems/componentsmostly implemented in Java and C/C++. Some of thosecomponents are developed by third-party contributors ofthe Android open source project (AOSP), such as originalequipment manufacturers (OEM) and Linux contributors.The Android OS stack is composed by the following layers:
Applications: software running on the device that usesthe Android APIs to implement specific features, like geo-localization. The components in this layer are the mobile “apps"we use daily such as Browser, Calendar, and Settings; theseapps are mostly written in Java.
Android Framework: provides apps (and developers)with the building blocks and common tasks required forexposing/using device- and Android-specific features such asmanaging UI elements and sensors. The Android Frameworkcontains the Android APIs and Android managers ( a.k.a., services); examples of these services are the View Systemand the Activity Manager. This layer is implemented in Java.
Runtime: contains the Virtual Machine (Dalvik/ART) andthe core libraries required for the execution of apps and serviceson the device. Runtime is required for ensuring apps portabilityacross different devices. Examples of the core libraries in theRuntime layer are the independent implementation of Java usedby Android and the Bouncy castle library.
Native Libraries: provide low level functionality andcomputational intensive services required by the AndroidFramework and the Runtime, such as the Bionic libc library,the WebKit browser engine, OpenGL, SSL, and the MediaFramework. The libraries are written in C/C++.
Hardware Abstraction Layer (HAL): it is thebridge between the high level representations of the hardwareused in the libraries, and low level representations used by the kernel. It is a set of interfaces for hardware-specificsoftware that needs to be implemented by OEMs and hardwaremanufacturers. Components in the HAL are written in C/C++.
Linux Kernel: it provides the Android OS with coreOS systems infrastructure, a security model, networking, andmemory and process management, among the others. Androiduses a modified version of Linux tailored to mobile devices.For more details of the Android OS architecture, we pointthe interested reader to the following sources: [19]–[21].
A. Malware and Vulnerabilities
The wide and rapid adoption of Android-based devices inthe last years has motivated the usage of Android apps tosupport a broad range of daily activities. In that sense, beingthe most popular mobile platform makes it an attractive targetfor security attacks [22]. In fact, the number and complexity ofthe attacks to Android-based systems is increasing drastically[22]; since 2008, Android-related vulnerabilities have beenreported including critical issues such as the “Heartbleed"[23] flaw in the SSL library, and the “Stagefright" flaw in themedia framework [7]–[9] that has infected 95% of the Androiddevices in 2015. As a consequence, the industry has improvedthe security mechanisms and services in the Android ecosystem[24] and designed mobile-specific malware detectors.Researchers have also contributed to improve the security ofthe Android ecosystem by analyzing security vulnerabilities andproposing improvements to current security models [12], [16],[17], [22], [25]–[32], [32]–[35]; however, while the focus of theacademic research has been the security of the applications—the closest component to the user—, the core of the Androidecosystem ( i.e., the Android OS) has received little attention.
1) Security in Android Applications:
Android malware andvulnerabilities in Android apps are characterized by a novel setof flaws that exploit user level weaknesses and the issues insecurity mechanisms of the Android OS. For instance, Android-specific attacks include (i) privileges/permissions escalationthrough pairs of infected apps that exploit inter-applicationcommunication or misconfigured apps [10]–[12], [35], [36],(ii) applications tapjacking/hijacking by apps repackagingand substitution [26], (iii) information leaking through covertchannels [37], [38], (iv) SSL vulnerabilities in hybrid [33]and native apps [32], (v) security issues introduced by thirdparty libraries [34], and (vi) security issues introduced byOS customizations [28]. These novel attacks, in addition toclassic security attacks induced by malware ( e.g.,
DoS), havebeen widely studied by the community and several approacheshave been proposed for their detection and mitigation, suchas TaintDroid [39], COVERT [10], [11], FlowDroid [40],MudFlow [41], Chabada [42], Q-Floid [43], and AppInspector[44]. Other resources, like the Android Malware GenomeProject (Malgenome) [45], aim at characterizing Androidmalware families by describing installation methods, activationmechanisms, and malicious payloads; the Malgenome projectincludes 1,200 malware samples collected from August 2010 toOctober 2011. For more details we refer the interested readerto the works by Zhou et al. [29] and Sufatrio et al. [30] thatidely describe Android malware and detection techniques,and a recent work by Sadeghi et al. [31] presenting a surveyof static analysis techniques for detecting Android malware.
2) Android OS Vulnerabilities:
Previous studies focusedon the analysis of specific components of the OS and theirsecurity issues. Bagheri et al. [16] analyzed the vulnerabilitiesof the permission system in the OS; Cao et al. [17] analyzedinput validation mechanisms in the services/managers of the
Android Framework ; Huang et al. [22] found 4 vulnera-bilities ( a.k.a.,
Android Stroke Vulnerabilities) in two servicesof the
Android Framework ( i.e., Activity and WindowManager) that can be used for DoS attacks and for inducing OSsoft-rebooting; Wang et al. [27] also analyzed the
AndroidFramework layer and found six unknown vulnerabilities inthree of its services ( i.e.,
Activity Manager, Location Manager,Mount Service), and two apps from the
Applications layer( i.e.,
SystemUI, Phone).
3) Mining-Based Studies:
Closer to our study are theprevious works aimed at analyzing security vulnerabilitiesby following a mining-based approach. Some of those studiesare Android-specific [13]–[15] while others are more generalin the sense that they aim at characterizing security bugs[46], [47]. Thomas et al. [14] mined the OS updates installedon 20k+ Android devices to measure the delivery time ofsecurity updates for 11 vulnerabilities, and to establish ascoring model of insecure devices; the results suggest that,on average, 87.7% of the devices are exposed to at least one ofthe analyzed vulnerabilities. Thomas [13] investigated the CVE-2012-6636 [48] vulnerability on the JavaScript-to-Java interfaceof the WebView API; 102k+ APKs were statically analyzed tomeasure the number of apps in which the vulnerability couldbe exploited. In addition, the lifetime of the vulnerability wasanalyzed using an approach similar to [14].Finally, Jimenez et al. [15] analyzed 32 vulnerabilitiesfrom the CVE database [49] to identify the issues, involvedcomponents, code complexity of the patches, and complexityof the code methods/functions involved in the vulnerability.The study presented in this paper is complementary toprevious studies in the sense that a larger set of vulnerabilities(mined from CVE) is analyzed (660) and different perspectivesare included in the study such as the survivability time of thevulnerabilities, subsystems and components of the AndroidOS involved in the vulnerabilities, an extensive taxonomy ofsecurity issues based on the Common Weakness Enumeration(CWE) hierarchy of vulnerabilities [50], and a list of learnedlessons oriented to Android OS and apps developers.III. S
TUDY D ESIGN
The goal of the study is to investigate Android-relatedsecurity vulnerabilities reported over the past eight years ( i.e., the whole history of the Android OS). The purpose is to (i)define a taxonomy highlighting the types of Android-relatedvulnerabilities as well as which of the Android OS subsystemsare more exposed to security issues, and (ii) investigate the timeneeded to fix vulnerabilities in Android. The context consistsof 660 vulnerabilities mined from CVE Details [6], [49], a cveId : The id of the vulnerability, score : A score from 0 to 10 indicating the severity of the vulnerability, description : A textual description of the vulnerability, patchLinks : [Links to the patch(es) aimed at fixing this vulnerability], type : [The type of the vulnerability automatically inferred], confidentialityImpact : ability to access information ( None/Partial/Complete) , integrityImpact : ability to modify information in the device ( None/Partial/Complete) , availabilityImpact : impact on the availability of the device ( None/Partial/Complete) , accessComplexity : complexity of the attack required for the exploition ( Low/Med./High ) Fig. 1. Information stored for the vulnerabilities mined from CVE Details vulnerability datasource processing XML feeds provided bythe National Vulnerability Database [18]. All the data used inthe study are available in our online appendix [51].The study addresses the following research questions: RQ : Which types of security vulnerabilities affect Android?
This research question aims at identifying the types ( e.g., inad-equate encryption strength) of Android-related vulnerabilitiesreported over the past eight years. Note that with “Android-related” we refer to both vulnerabilities directly affecting codecomponents belonging to the Android OS, i.e., the componentsof the Android software stack developed by Google, as wellas those related to third-party components ( e.g., hardwaredrivers, apps shipped with the devices) threatening the securityof Android devices. Also, we investigate (i) the impact on confidentiality , integrity , and availability of the vulnerabilities(see Fig. 1 for a definition of these three properties), and (ii) thecomplexity of the attack required to exploit the vulnerabilities( accessComplexity in Fig. 1). RQ : Which are the Android subsystems more affected bysecurity vulnerabilities?
The second research question shedsthe light on the Android subsystems more frequently affectedby security vulnerabilities. Note that in this case our focuswill be on the architecture of the Android OS, while lessemphasis will be given to vulnerabilities affecting third-partycomponents. Indeed, our goal is to point out to developers(both apps developers as well as contributors of the AndroidOS) which are the more risky services, APIs, apps, etc. , in theOS. This information can be used to better focus verification& validation activities as well as to develop better Android-specific tools for vulnerability detection and secure coding. RQ : How long does it take to fix security vulnerabilitiesin Android?
This research question studies the survivability ofthe security vulnerabilities subject of our study. In particular,we assess the number of days between the vulnerabilityintroduction and its fixing. RQ ’s findings could help inassessing the usefulness of effective vulnerability detectiontools able to immediately catch an introduced vulnerability( i.e., a long survivability of the vulnerabilities would indicatethe urge for such tools), and to identify the prevalence ofvulnerabilities across different versions of the OS. A. Data Extraction and Analysis
The context of the study consists of 660 vulnerabilitiesmined from the official Android Security Bulletins and theCVE Details website [49]. The information was collected onNovember 24, 2016. First, we built a web-based scraper thatwent over all the 16 bulletins published by Google from August2015 until November 2016, looking for CVE ids (using regularxpressions). In total, we found 564 CVE ids in the AndroidBulletins; 62 of them are reported as reserved, meaning thatthe details of the vulnerability are not publicly available.A second web scraper was then used to automaticallyextract the details of each of the vulnerabilities listed in CVEdetails under the category “Android” [6]; we collected 629vulnerabilities from CVE details under the “Android” category.Some of the non-reserved vulnerabilities (listed in thebulletins) do not appear tagged as Android-related in the CVEdetails website because they affect the Linux Kernel or thirdparty components ( e.g., drivers). We found 31 vulnerabilitiesin the bulletins not tagged as Android-related in CVE details.Therefore, using the CVE ids from the bulletins we directlyscraped the information from CVE details, without relyingon the Android filter. At the end, we obtained informationfor a total of 660 vulnerabilities (629 tagged as Android-related + 31 not tagged as Android but listed in the bulletins).Note that 159 of the collected 660 vulnerabilities are notlisted in the bulletins; those CVEs are mostly from drivers,apps, and OS modifications of device manufacturer/vendors,and vulnerabilities found before the first Google bulletin waspublished (August 13, 2015).For each of the selected vulnerabilities we stored a
JSON file reporting the information detailed in Fig. 1. This data wascomplemented/fixed via manual analysis (as detailed below),and then used to answer RQ and RQ . In particular, onceextracted the information in Fig. 1 for each vulnerability, twoauthors manually analyzed each vulnerability to:
1. Check and complement the vulnerability type automaticallyinferred by CVE Details, and obtain its hierarchy . CVE Detailsexploits a keywords-based mechanism to automatically infer thetype of each vulnerability according to the Common WeaknessEnumeration (CWE) dictionary [50]. Such an automatic processcan introduce imprecisions in the data. For this reason, twoauthors analyzed all the information available about eachvulnerability ( i.e., its page on the National VulnerabilityDatabase, fixing patches when publicly available, officialvulnerability bulletins, the Android issue tracker, etc. ) to verifythe type of the vulnerability, identify the CWE hierarchy,and consequently change/complement the classification (stillaccording to the CWE dictionary). Note that a vulnerabilitycan belong to multiple types having hierarchical relationshipsbetween them. For example, a vulnerability can be classifiedas (from the least to the most specialized category):
Improper Restriction of Operations within the Bounds of aMemory Buffer → Out-of-bounds Read → Buffer Over-read
Overall, the manual analysis led to the change or comple-menting ( i.e., multiple types are assigned to the vulnerability,including the one automatically inferred by CVE Details) ofthe type provided by CVE Details for 68% of the analyzedvulnerabilities.
2. Identify the subsystems affected by the vulnerability . Theauthors analyzed the information in the National VulnerabilityDatabase (including, when available, the patches fixing thevulnerability) as well as online documentation ( e.g., the Androidissue tracker) to identify the code components affected by the vulnerability. Firstly, a high-level classification was performed( i.e., the vulnerability affects the Android OS componentsdeveloped by Google or third-party components).Then, for the vulnerabilities affecting the Android OS, amore fine-grained category was defined in order to identify theaffected architectural layer ( e.g., Android runtime ) and, morespecifically, the affected subsystem ( e.g., Dalvik VM ).The above described manual analysis was performed inthree rounds. First, two authors ( A and A ) manuallyanalyzed half of the 660 vulnerabilities each. Then, A checked the vulnerability types and the impacted architecturallayers/subsystems assigned by A and vice versa . Finally,the authors discussed the 47 (7%) cases of disagreement,reaching an agreement on the correct classification needed. Onevulnerability ( CVE-2016-3877 ) has been excluded from thestudy at this stage, since no information was available about it.Also, in cases in which the two evaluators were undecided aboutthe specific type of vulnerability and/or about the subsystemaffecting the vulnerability, an “unclear” tag was assigned.We answer RQ by presenting a taxonomy of the typesof vulnerabilities identified in the manual analysis as well asdescriptive statistics about their characteristics ( e.g., impact on confidentiality ). The characteristics have not been manuallyvalidated since they are mined by CVE Details directly from theNational Vulnerability Database [18]. Thus, we assume themas correct. Concerning RQ , we report a heat map showing thedistribution of vulnerabilities across the Android subsystems.We complement our discussion with qualitative examples.To answer RQ we need information not available in theCVE Details datasource. In particular, we need to identifythe commits in which each vulnerability has been introducedand fixed. As for the commit fixing each vulnerability, wemined it from the Android Security Bulletins [52], issuedeach month and reporting about the recently identified/fixedvulnerabilities. The vulnerability-fixing commit is not availablefor all the 660 Android-related vulnerabilities we collected fromthe CVE Details datasource, because (i) some vulnerabilitieswere reported before the first available bulletin, and (ii) thefixing commit (see e.g., http://tinyurl.com/hrod7q9) is onlyavailable for the subset of vulnerabilities fixed in the Androidopen source project ( e.g., it is not available for vulnerabilitiesrelated to third-party components such as drivers). Note alsothat, although the CVE reports include in some cases thebug id, the ids are for the internal bug trackers of Googleand hardware manufactures, which are not publicly available.For these reasons, the analysis for RQ is limited to a set of201 vulnerabilities for which we identified the fixing commit.Once identified the fixing commit, we used the SZZ algorithm[53] to identify the commit introducing the vulnerability. Thealgorithm relies on the annotation/blame feature of versioningsystems. Given a vulnerability-fixing commit VF k (where k identifies the vulnerability), the approach works as follows:1. For each file f i , involved in VF k and fixed in its revision rel-fix i,k , we extract the file revision just before the vulnerabilityfixing ( rel-fix k − ).2. Starting from the revision rel-fix k − , for each sourceode line in f i changed to fix the vulnerability k , the blame feature of Git is used to identify the file revision where thelast change to that line occurred.In doing that, blank lines and lines that only containcomments are identified using an island grammar parser [54].This produces, for each file f i , a set of n i,k fix-inducingrevisions rel-vulnerability i,j,k , j = 1 . . . n i,k .Since more than one commit can be indicated by the SZZalgorithm as responsible for inducing the vulnerability-fix,there are time vulnerability ranges defined by lower (minimumsurvivability) and upper bounds (maximum survivability).Therefore, we answer RQ by following a meta analysis-based procedure [55], [56]: The minimum and the maximumsurvivability of the vulnerabilities ( i.e., number of days betweenthe vulnerability introduction and fixing) are plotted usingforest plots with confidence intervals, and a central tendencymeasure of the survivability is computed by using the randomeffects model [56] (based on the recommendations by Cumming[56]). The minimum survivability is the one observed whenconsidering the most recent commit identified by the SZZalgorithm as the one that induced the vulnerability-fix. Viceversa , the maximum survivability is observed when consideringthe least recent commit identified by the SZZ algorithm asthe one that induced the vulnerability-fix. The forest plots aredepicted by considering a 95% confidence interval.We also verify whether vulnerabilities having differentseverity levels have different survivability. For this analysis, weuse the severity classification available in the Android bulletins( low , moderate , high , and critical ). In particular, we comparethe distributions of the survivability of the different categoriesof vulnerabilities ( e.g., low vs. moderate ) via (i) forest plots,and (ii) statistical tests. For the latter we exploit the Mann-Whitney test [57] with results intended as statistically significantat α = 0 . . To control the impact of multiple pairwisecomparisons ( e.g., the survivability of the vulnerabilities having low severity is compared against the survivability of thosehaving moderate , high , and critical severity), we adjust p -values using the Holm’s correction [58]. We also estimate themagnitude of the differences by using the Cliff’s Delta ( d ), anon-parametric effect size measure [59] for ordinal data. Wefollow well-established guidelines to interpret the effect size:negligible for | d | < . , small for . ≤ | d | < . , mediumfor . ≤ | d | < . , and large for | d | ≥ . [59].IV. R ESULTS
This section discusses the quantitative results achieved inour study according to the three formulated RQs. Also, wecomplement quantitative data with qualitative examples, byreferring to specific vulnerabilities identified with their CVEid ( e.g.,
CVE-2016-2439 ). The reader can access the pagedetailing a vulnerability by visiting “https://web.nvd.nist.gov/view/vuln/detail?vulnId=” followed by the CVE id. Due tothe lack of space we only discuss a limited set of examples.However, in our online appendix [51] we provide the completelist of vulnerabilities considered in our study, including theircategorization by subsystem, component, and vulnerability type. Also, we created visualizations aimed at helping the readerwhen browsing the vulnerabilities list [51].
A. Which types of security vulnerabilities affect Android?
Fig. 2 shows the taxonomy reporting the vulnerability typeswe found in the 660 manually inspected vulnerabilities. Asexplained in Section III-A, the vulnerability types are depictedin a hierarchical manner by following the categorizationprovided in the CWE dictionary [50]. Note that Fig. 2 onlyreports the classification for 510 vulnerabilities. This is dueto the fact that we were not able to infer the type of 150vulnerabilities during our manual analysis.The vulnerabilities most frequently affecting Android devicesare those related to weaknesses that affect the memory ,with 103 instances (20%). These weaknesses include allvulnerabilities related to the improper restriction of operationsin the bounds of memory buffer , like out-of-bounds read/write .One vulnerability falling in this category is
CVE-2016-2439 ,described as follows:
Buffer overflow in btif_dm.c in Bluetooth [...] allowsattackers to execute arbitrary code via a long PIN value
The vulnerability was fixed in commit , modify-ing the conditional statement checking a PIN-related errorfrom if (pin_code == NULL) to if (pin_code ==NULL || pin_len > PIN_CODE_LEN) . The rationalebehind the change is also documented by the developer inthe commit message:
If a malicious client set a pin that wastoo long it would overflow the pin code memory .Very popular are also vulnerabilities related to data han-dling , typically found in functionalities that process data [50](74 instances—15%). These include, for example, type errors like the one related to
CVE-2016-3918 : AttachmentProvider.java in AOSP Mail in Android [...] doesnot ensure that certain values are integers, which allowsattackers to read arbitrary attachments [...]
The vulnerability was fixed in commit that, asreported in the commit message:
Limits account id and idto longs [...] Both id and account id are now parsed intolongs (and if either fails, an error will be logged and null willbe returned) . Note that the data handling category includesseveral different sub-categories that we do not detail due tolack of space (see Fig. 2).Vulnerabilities related to permissions, privileges, and ac-cess control are represented in our taxonomy with 58 instances(11%). They include, for example, weaknesses due to improperaccess control and to permission issues , like the cookie forcing vulnerability discussed in
CVE-2008-7298 : The Android browser cannot properly restrict modificationsto cookies established in HTTPS sessions, which allowsman-in-the-middle attackers to overwrite or delete arbitrarycookies via a Set-Cookie header in an HTTP response [...]
Improper input validation (51 instances—10%) includesvulnerabilities caused by a missing or improper validation ofinputs that can affect the control/data flow of the program [50]. nd r o i d -r e l a t e d V u l n e r a b iliti e s B e h av i o r a l p r ob l e m s D a t a h a nd li n g I m p r op e r c h eck o r h a nd li n g o f exce p t i on a l c ond i t i on s I m p r op e r f u l fi ll m e n t o f A P I c on t r ac t W eak n e ss e s t h a t a ff ec t fi l e s o r d i r ec t o r i e s I n i t i a li za t i on a nd c l ea nup e rr o rs I n j ec t i on fl a w s P e r m i ss i on s , p r i v il ege s , a nd acce ss c on t r o l T i m e a nd s t a t e Po i n t e r i ss u e s I m p r op e r i npu t va li d a t i on I nd i ca t o r o f poo r qu a li t y c od e W eak n e ss e s t h a t a ff ec t m e m o r y B u s i n e ss l o g i c e rr o r s I m p r op e r acce ss o f i nd exa b l e r e s ou r ce N u m e r i c e rr o r s I n f o r m a ti on m a n age m e n t e rr o r s I m p r op e r h a nd li n g o f s y n t ac ti ca ll y i n va li d s t r u c t u r eS t r i n g e rr o r s T y p e e rr o r s I n t ege r c o e r c i on e rr o r I n c o rr ec t ca l c u l a ti on S i g n e d t o un s i g n e d c on ve r s i on e rr o r I n t ege r und e r flo w O ff - b y - on e e rr o r I n t ege r o ve r flo wU s e o f ex t e r n a ll y - c on t r o ll e d f o r m a t s t r i n g I n f o r m a ti on ex po s u r e I n f o r m a ti on ex po s u r e t h r ou g h a n e rr o r m e ss age I n f o r m a ti on ex po s u r e t h r ou g h s e n t d a t a Ex po s u r e t h r ou g h s e lf - ge n e r a t e d e rr o r m e ss ageE rr o r h a nd li n g U n ca u g h t Exce p ti on I m p r op e r va li d a ti on o f a rr ay i nd ex U n c h ecke d e rr o r c ond iti on I n c o rr ec t u s e o f p r i v il ege d A P II m p r op e r li m it a ti on o f p a t hn a m e t o r e s t r i c t e d dd i r ec t o r y U n r e s t r i c t e d up l o a d o f fi l e s w it h d a n ge r ou s t y p e R e l a ti ve p a t h t r ave r s a lI n c o m p l e t e c l ea nup I m p r op e r i n iti a li za ti on M i ss i n g i n iti a li za ti on o f va r i a b l e M i ss i n g i n iti a li za ti on o f r e s ou r ceSe n s iti ve i n f o r m a ti on un c l ea r e d b e f o r e r e l ea s e S Q L i n j ec ti on C o mm a nd i n j ec ti on C od e i n j ec ti on I m p r op e r acce ss c on t r o l P e r m i ss i on i ss u e s P r i v il ege / s a ndbo x i ss u e s C oo k i e f o r c i n g I n c o rr ec t d e f a u lt p e r m i ss i on s I m p r op e r o w n e r s h i p m a n age m e n tI m p r op e r p r i v il ege m a n age m e n t Ex po s e d I O C T L w it h i n s u f fi c i e n t acce ss c on t r o l I n s u f fi c i e n t c on t r o l flo w m a n age m e n t Ex po s u r e o f r e s ou r ce t o w r on g s ph e r e R e t u r n i n g a m u t a b l e ob j ec t t o un t r u s t e d ca ll e r R ace c ond iti on Exce ss i ve it e r a ti on L oop w it h un r eac h a b l e ex it c ond iti on Ex p i r e d po i n t e r d e r e f e r e n ce A cce ss o f un i n iti a li ze d po i n t e r U n t r u s t e d po i n t e r d e r e f e r e n ce R e l ea s e o f i n va li d po i n t e r o r r e f e r e n ce NU LL po i n t e r d e r e f e r e n ce A ss i g n m e n t o f a fi xe d a dd r e ss t o a po i n t e r U s e o f ou t - o f -r a n ge po i n t e r o ff s e t U s e a ft e r f r ee I m p r op e r va li d a ti on o f f un c ti on a r g u m e n t s I m p r op e r nu ll t e r m i n a ti on I m p r op e r c on t r o l o f r e s ou r ce i d e n ti fi e r s I n t ege r o ve r flo w t o bu ff e r o ve r flo w T ec hno l o gy - s p ec i fi c i npu t va li d a ti on p r ob l e m s U s e o f m u lti p l e r e s ou r ce s w it h dup li ca t e i d e n ti fi e r I m p r op e r c on t r o l o f i n t e r ac ti on f r e qu e n cy I n c o rr ec t b e h av i o r o r d e r I m p r op e r n e u t r a li za ti on o f d e li m it e r s I m p r op e r n e u t r a li za ti on o f li n e d e li m it e r s I m p r op e r h a nd li n g o f p a r a m e t e r s Fa il u r e t o h a nd l e m i ss i n g p a r a m e t e r I n f o r m a ti on ex po s u r e t h r ou g h d e bu g i n f o r m a ti on I m p r op e r r e s t r i c ti on o f c o mm . c h a nn e l t o i n t e nd e d e ndpo i n t s I m p r op e r ex po r t o f A nd r o i d a pp li ca ti on c o m pon e n t s I n s u f fi c i e n t e n ca p s u l a ti on Ex po s e d d a n ge r ou s m e t hod o r f un c ti on R ace c ond iti on w it h i n a t h r ea d U s e o f un i n iti a li ze d va r i a b l e N on - ex it on Fa il e d I n iti a li za ti on U n c h ecke d r e t u r n va l u e U n c h ecke d i npu t f o r l oop c ond iti on U s e o f po t e n ti a ll y d a n ge r ou s f un c ti on R e s ou r ce m a n age m e n t e rr o r s I n c o rr ec t r e s ou r ce t r a n s f e r b e t w ee n s ph e r e s D oub l e f r ee D e s e r i a li za t. o f un t r u s t e d d a t a R e s ou r ce l o ck i n g p r ob l e m s I m p r op e r r e s ou r ce s hu t do w n o r r e l ea s e U n c on t r o ll e d r e s ou r ce c on s u m p ti on U n r e s t r i c t e d up l o a d o f fi l e w it h d a n ge r ou s t y p eL o gg i n g o f exce ss i ve d a t a A ll o ca ti on o f r e s ou r ce s w it hou t li m it s o r t h r o ttli n g U n c on t r o ll e d m e m o r y a ll o ca ti on I m p r op e r r e s t r i c ti on o f op e r a ti on s i n t h e bound s o f m e m o r y bu ff e r A cce ss o f m e m o r y l o ca ti on a ft e r e nd o f bu ff e r B u ff e r c op y w it hou t c h eck i n g s i ze o f i npu t B u ff e r acce ss w it h i n c o rr ec t l e n g t h va l u e I n c o rr ec t ca l c u l a ti on o f bu ff e r s i ze O u t - o f - bound s w r it e O u t - o f - bound s r ea d B u ff e r o ve r-r ea d B u ff e r acce ss u s i n g s i ze o f s ou r ce bu ff e r H ea p - b a s e d bu ff e r o ve r flo wU s e o f ou t - o f -r a n ge po i n t e r o ff s e t B u ff e r und e r w r it eS t ack - b a s e d bu ff e r o ve r flo w Sec u r i t y f ea t u r e s C r y p t o g r a p . i ss u e s U s e r i n t e r f ace s ec u r it y i ss u e s U s e o f i n s u f fi c i e n tl y r a ndo m va l u e s I m p r op e r ce r ti fi ca t e va li d a ti on I m p r op e r a u t ho r i za t. C r e d e n ti a l s m a n age m e n t I n s u f fi c i e n t ve r i fi ca ti on o f d a t a a u t h e n ti c it y I m p r op e r a u t h e n ti c . M i ss i n g r e qu i r e d c r y p t o g r a ph i c s t e p I n a d e qu a t e e n c r y p ti on s t r e n g t h U s e o f a b r o ke n o r r i s ky c r y p t o g r a ph i c a l g o r it h m K ey m a n age m e n t e rr o r s M i ss i n g e n c r y p ti on o f s e n s iti ve d a t a C l ea r t ex t t r a n s m i ss i on o f s e n s iti ve i n f o r m a ti on W eak p a ss w o r d r ec o ve r y m ec h a n i s m M i ss i n g a u t ho r i za ti on I n c o rr ec t p e r m i ss i on a ss i g n m e n t f o r c r iti ca l r e s ou r ce I m p r op e r f o ll o w i n g o f ce r ti fi ca t e ' s c h a i n o f t r u s t P r e d i c t a b ilit y p r ob l e m s Se ss i on fi xa ti on M i ss i n g c r iti ca l s t e p i n a u t h e n ti ca ti on C r o ss - s it e s c r i p ti n g I m p r op e r ve r i fi ca ti on o f c r y p t o g r a ph i c s i g n a t u r e M i ss i n g r e qu i r e d c r y p t o g r a ph i c s t e p U s e o f a b r o ke n o r r i s ky c r y p t o g r a ph i c a l g o r it h m F i g . . R Q : T yp e s o f A nd r o i d -r e l a t e dvu l n e r a b iliti e s onfidentialityintegrityavailability
13% 28% 59%20% 16% 64%19% 15% 66%
Fig. 3. RQ : Impact of the vulnerability exploitation Vulnerabilities in this category include (but are not limited to—see Fig. 2) unchecked input for loop condition and impropervalidation of function arguments .The latter are the most popular in this category and,while their fixing is generally simple ( e.g., the addition of amissing/improper argument validation), they can result in severeattacks like the one possible by exploiting
CVE-2016-3910 (9.3 out of 10 in severity score).
Security features are involved in 44 vulnerabilities (9%)related to cryptographic issues , user interface security issues , credentials management problems, etc. (see Fig. 2). Forexample, CVE-2011-2344 reports a vulnerability due to inadequate encryption strength possibly causing severe attacksallowing the stealing of private pictures:
Android Picasa in Android [...] uses a cleartext HTTPsession when transmitting the authToken obtained fromClientLogin, which allows remote attackers to gain privi-leges and access private pictures and web albums by sniffingthe token from connections with picasaweb.google.com
Initialization and cleanup errors and improper checkor handling of exceptional conditions are the cause for 33and 30, respectively, of the categorized vulnerabilities ( ∼ missinginitialization of a variable and uncaught exceptions .Finally, other less diffused vulnerabilities are those falling inthe categories: Indicator of poor quality code (27 instances), behavioral problems (21), time and state (14), injectionflaws (6), improper fulfilment of API contract (4), and weaknesses that affect files or directories (3). A descriptionof these categories can be found in the CWE dictionary [50],while Android-related examples from our dataset are availablein our online appendix [51].
1) Characteristics of the Android-related vulnerabilities:
Wediscuss the characteristics of the vulnerabilities in terms of theiraccess complexity and availability, integrity, and confidentialityimpact (see Fig. 1 for a definition of these characteristics).
Access complexity.
Very few vulnerabilities (21) require ahigh access complexity, meaning that (i) the vulnerability isdifficult to exploit, and (ii) specific conditions must verify toallow the exploitation. Most of the vulnerabilities have eithera medium (399) or low (238) access complexity. Note thathaving a low access complexity ( i.e., very little knowledgeneeded to exploit the vulnerability) does not imply a lowerseverity for the effects for the exploitation. Indeed, 130 of thesevulnerabilities in our dataset ( i.e.,
55% of all those having alow access complexity) cause a complete confidentiality ( i.e., total information disclosure), integrity ( i.e., total compromiseof system integrity), and availability ( i.e., total unavailabilityof the targeted device resources, like CPU) impact. Impact of the exploitation.
Fig. 3 reports the impact onconfidentiality, integrity, and availability of the studied vulner-
Applications
BluetoothBrowser EmailTelephony SMS/MMS
Application Framework
Content ProvidersActivity ManagerWi-Fi Package Manager Lock Setting Service Other (13 subs. with 1 vulnerability each)
Telephony Manager View System
Native Libraries
DebuggerdlibcMedia Framework OpenGL/ESSSL
Android Runtime
Core LibrariesDalvik VM
Hardware Abstraction Layer (HAL)
BinderMemory Drivers Wi-FiThird-party AppsThird-party LibrariesThird-party Drivers System ServerSettingsSetup Wizard
Linux Kernel
Other (10 subs. with 1 vulnerability each)
TelephonyExternal Storage Wi-FiBoot Loaderlibutils Binder BluetoothCamera Shared Memory Other (11 subs. with 1 vulnerability each)
Media Binder
Fig. 4. RQ : Heat map of vulnerabilities in the Android layers/subsystems abilities. Green indicates no impact , orange a partial impact ,and red a complete impact .Most of the Android-related vulnerabilities can seriouslycompromise the confidentiality and integrity of the informationstored in the device and can cause a complete exhaustion of thedevice’s resources. This highlights the urge for techniques andtools supporting the detection of Android-related vulnerabilitiesat different stages: development, submission to the market, andexecution in the device. B. Which are the Android subsystems more affected by securityvulnerabilities?
Fig. 4 depicts (using a heat-map style), the manuallyidentified layers and subsystems of the Android OS impactedby 634 vulnerabilities. For building the heatmap, from the 660vulnerabilities dataset, we excluded 26 in which we were notable to manually identify the layer. For the heat-map we usedtwo color schemes: white-to-red for the layers, with whiterepresenting the lowest value and red the highest one; andwhite-to-yellow for the subsystems ( i.e., internal boxes), withfull yellow meaning that a subsystem is responsible for 100%of the vulnerabilities in the corresponding layer. Note thatthe subsystems’ colors are normalized on the basis of thetotal vulnerabilities affecting a layer. Fig. 4 also reports thepercentage of vulnerabilities affecting each layer.
Linux Kernel is the most frequently affected layer, with261 of the 634 vulnerabilities (41%). It is worth notingthat the Android Open Source Project includes modificationsto the original kernel to enable mobile features. However,ost of the vulnerabilities in this layer affect third-partydrivers developed by hardware manufactures (OEMs): 237vulnerabilities are in third-party drivers, while only 14 arefrom Google changes/contributions to the kernel and arerelated to Android-specific components such as
Binder , ashmem/Shared memory , and aboot/Boot loader .For 10 of the 261 vulnerabilities we were not able to identifywhether they affect kernel components contributed by Google orby OEMs. For third-party drivers, Video , WiFi , and
Camera are the top three hardware components/features involved in thevulnerabilities. In the case of the Android-specific components,most of the reported vulnerabilities (8 out of 14) are locatedin the
Bootloader , and correspond to overflow/over-readissues, improper check or handling of exceptional conditions[60], improper access control [61], and weak password recoverymechanism [62].The
Native libraries layer is the second one exhibit-ing the largest number of vulnerabilities (201 out of 634 =31.7%). This is mostly due to the
Media Framework subsys-tem that has suffered of 143 vulnerabilities (129 from Googlecontributions, 14 from third party contributions), including theset of issues known as “Stagefright" [7]–[9] that are sourcedin the
Stagefright library ( a.k.a., libstagefright). In thecase of third-party files, the vulnerabilities are in librariessupporting the
Media framework , WiFi , Bluetooh , and
DHCP services, and the
Skia library. Vulnerabilities in the
Media Framework are mostly related to issues with pointers[63], arrays access/writing, and memory management that leadto any type of overflow/underflow when accessing, writing,creating, and copying buffers [64]–[66], and when perform-ing integer operations [67]. For instance, the vulnerability
CVE-2015-3834 reported as fixed in the August 2015bulletin has the following CVE description:
Multiple integer overflows in the BnHDCP::onTransactfunction in libstagefright allow attackers to execute ar-bitrary code via a crafted application that uses HDCPencryption, leading to a heap-based buffer overflow [...]
This vulnerability was fixed with the commit c82e31a that modifies the
IHDCP.cpp file. The lack of buffer sizevalidation when computing a buffer size, was leading to heap-based buffer overflows [66] when creating an input buffer withthe calculated size. Another example of security issue in the
Media Framework related to improper validation/restrictionof operations within the bounds of a memory buffer is
CVE-2016-0815 : The MPEG4Source::fragmentedRead function inMPEG4Extractor.cpp in libstagefright in mediaserver [...]allows remote attackers to execute arbitrary code or causea denial of service (memory corruption) via a craftedmedia file [...]
The issue can be summarized as an out-of-bounds write [68]generated when an array offset goes beyond the buffer size.The vulnerability was fixed in commit .The
Applications layer is the top three in the list with 88vulnerabilities located in 18 applications developed by Google, and 10 third-party apps.Concerning the third-party applications, the
Adobe FlashPlayer is the most vulnerable app with 29 vulnerabilities;the next more vulnerable app is
Firefox (4 vulnerabilities);
Nvidia Profiler , Widevine QSEE trustzone and
Samsung OMACP are the top three with 3 vulnerabilitieseach. From the 18 apps developed by Google,
Browser , Telephony , and
SMS/MMS have been the most vulnerablewith 5 vulnerabilities each.Vulnerabilities in the
Applications layer are diversein terms of types. For example, the Android
Browser hada vulnerability (
CVE-2011-0680 ) impacting 6 differentversions of the OS (before 2.3.4) which: [...] allows remote attackers to obtain SD card contents viacrafted content:// URIs, related to (1) BrowserActivity.javaand (2) BrowserSettings.java [...]
The
CVE-2011-0680 vulnerability is an example of infor-mation exposure through sent data [69] because of the lack ofURIs validation in the
Browser app.The next Android OS layer more affected by vulnerabilitiesis the
Android Framework with 46 vulnerabilities (7.26%)mostly located in the
Activity Manager and
PackageManager . While the former is in charge of tasks suchas intents resolution and app/activity launching, the lattermanages information and handle tasks related with the Androidpackages ( i.e., apps) installed in the device. Conversely to the
Libraries layer that exhibits a non-diverse set of vulner-abilities (in terms of the type), the
Android Framework has been affected by a diverse set of vulnerabilities includingcode injection [70], overflows [67], permission issues [71],business logic errors [72], missing authorizations [73], anduse of a risky cryptographic algorithm [74], among others. Anexample of vulnerability in the
Android Framework fromthe category “Business logic errors" is
CVE-2016-2500 : Activity Manager in Android [...] does not properly ter-minate process groups, which allows attackers to obtainsensitive information via a crafted application [...]
This vulnerability was a consequence of an invo-cation to the killProcessGroup method in the
ActivityManagerService.java file using wrong pa-rameters. Another example of vulnerability introduced bybusiness logic errors in the
Android Framework layeris
CVE-2016-3923 , in particular in the
AccessibilityServices that “ mishandle motion events, which allowsattackers to conduct touchjacking attacks and consequentlygain privileges via a crafted application ".The
HAL , and
Android Runtime layers are the onesless impacted by vulnerabilities with 19 and 14 vulnerabilities,respectively. The interface for media components is the most im-pacted component from
HAL . As for the
Android Runtime ,most of the vulnerabilities affect core libraries such as
ApacheHarmony , Bouncy Castle , and
Conscrypt ; only twovulnerabilities were reported for the
Dalvik VM . Finally,5 out of the 634 vulnerabilities (0.79%) vulnerabilities (notincluded in the heatmap) were manually assigned to different
Days
500 600 700 800 900 1,000 1,100 1,200 1,300 1,400 all lowmoderatehighcritical
Fig. 5. RQ : Survivability in days of Android-related vulnerabilities. Green(red) depicts minimum (maximum) estimates at 95% confidence interval. Blackshows the results of the random effect model. layers because the patches modified diferent layers of theAndroid OS stack; those vulnerabilities are CVE-2016-3760,CVE-2010-4832, CVE-2015-3843, CVE-2016-2496, and CVE-2016-3889. C. How long does it take to fix security vulnerabilities inAndroid?
Fig. 5 depicts the forest plots reporting the survivabilityof Android-related vulnerabilities ( i.e., the number of daysbetween the vulnerability introduction and its fixing). Asexplained in Section III-A, we report the minimum (green) andthe maximum (red) survivability intervals as computed withthe SZZ algorithm. In each forest plot the square representsthe average value of the distribution, while the line passingthrough it depicts the 95% confidence interval. Fig. 5 showsthe survivability intervals when considering all the analyzedvulnerabilities together (top part of Fig. 5) as well as whengrouping them by severity (low, moderate, high, and critical).Finally, the black line shown for the overall set of vulnerabilitiesdepicts the results of the random effects model [75], used inmeta-analysis to combine the results of different studies in asingle result outcome. In our case, the set of “different studies”includes the survivability estimates when considering theminimum ( study I ) and the maximum ( study II ) survivability.The first thing that leaps to the eyes from the analysis ofFig. 5 is the very long survivability of the analyzed Android-related vulnerabilities. Indeed, even when considering the mostconservative results ( i.e., the minimum estimated survivability—green line), the number of days needed to fix an introducedvulnerability is, on average, 724 (it grows to 907 for therandom effects model, and to 1,093 for the maximum estimatedsurvivability). It is important to note that this is not the numberof days needed to fix a vulnerability after it has been reported ,but after it has been introduced . This means that a vulnerabilitycould remain unnoticed in the system for years before beingidentified, possibly exploited, and then fixed. While it wouldhave been interesting to also analyze the time actually needed for the vulnerability fixing ( i.e., the number of days betweenthe vulnerability reporting and fixing), we did not find a wayto reliably identifying the reporting date.This very long survivability of the Android-related vulner-abilities was surprising for us at a first sight, especially dueto the young age of the Android OS. Thus, we manuallyinspected twenty randomly selected vulnerabilities in orderto verify whether strong imprecisions of the SZZ algorithmwere there affecting our findings. Note that such a sample isnot statistically significant, but just meant to show qualitativeexamples about the extracted data.Overall, we found the estimates provided by the SZZalgorithm to be precise. In particular, in 13 of the inspectedcases the SZZ identified a single commit as the vulnerability-fix-inducing one. In all these cases the identified commit wascorrect. In the remaining seven cases, multiple commits wereidentified by the SZZ algorithm as the possible responsiblefor the vulnerability introduction. In all these cases, either theminimum or the maximum vulnerability estimate was correct.In the following, we discuss some examples of manuallyinspected vulnerabilities.The vulnerability
CVE-2015-1538 has been reported inthe August 2015 security bulletin and is described as follows:
Integer overflow in the Sam-pleTable::setSampleToChunkParams function inlibstagefright in Android before 5.1.1 LMY48I allowsremote attackers to execute arbitrary code [...]
Such a vulnerability has been fixed in the commit cf1581c made on the 8th April 2015, having commit message
Fixseveral ineffective integer overflow checks and modifying thefile libstagefright/SampleTable.cpp . By inspect-ing the diff of such a commit, three lines were changed to fix theinteger overflows [76]. The SZZ algorithm correctly identifiesthe commit edd4a76e performed on the 28th July 2014 as thevulnerability-inducing commit (thus, the vulnerability survivedin the system for 254 days). Indeed, in such a commit thethree lines causing the integer overflows and then fixed wereintroduced all together, as it can be seen from the commit diff[77]. Note that this is one of those cases in which the SZZalgorithm identified a single commit as the responsible forinducing the vulnerability-fix. This was the case for 110 outof the 201 vulnerabilities (55%) considered in RQ .For the vulnerability CVE-2015-6608 we identified in-stead multiple commits as the possible responsible for thevulnerability introduction. This vulnerability is described asfollows: [...] allows remote attackers to execute arbitrary code orcause a denial of service (memory corruption) [...]
The vulnerability has been fixed in the commit (com-mit note: stagefright: check IMemory::pointer() before usingthe allocation ) made on the 15th May 2015 and modifying twolines [78] in media/libstagefright/ACodec.cpp .These two lines were modified for the last time by twodifferent commits, one performed on the 21st February 2012( i.e., ) and one performed on the 2nd May 2013 i.e., ). Each of these commits introduced one of thetwo lines then fixed in thus, they were both correctlyidentified as vulnerability-inducing commits.In this case, the commit contributes to the“minimum survivability distribution” depicted in green in Fig. 5(the survivability is 742 days), while contributesto the “maximum survivability distribution” depicted in redin Fig. 5 (survivability=1,179 days). Clearly, in this case thecorrect survivability estimate is 1,179, since the vulnerabilitywas there (at least in part) since the 21st February 2012.When looking for the survivability of vulnerabilities havingdifferent severity levels, we were not able to identify any cleartrend: It is not possible to assert that vulnerabilities having ahigher severity have a higher/lower survivability with respectto those having a lower severity (or vice versa ). This is visibleboth from the forest plots (see Fig. 5) and confirmed by thestatistical analysis, in which we did not observe any significantdifference (all the adjusted p -values were higher than 0.05).V. T HREATS TO V ALIDITY
Threats to construct validity concern the relation betweenthe theory and the observation, and in this work are mainly dueto the measurements we performed. This is the most importantkind of threat for our study, and is related to: RQ and RQ : Subjectivity in the manual classification . Weidentified through manual analysis the types of vulnerabilities(RQ ) and the subsystems (RQ ) they affect. To mitigatesubjectivity bias in such a process, two authors (A and A )manually analyzed half of the vulnerabilities each. Then, A checked the vulnerability types and the impacted subsystemsassigned by A and vice versa . Finally, the authors discussedthe cases of disagreement, reaching an agreement on the correctclassification needed. Also, when the type of the vulnerabilityand/or the impacted subsystem was unclear, we preferred toexclude the vulnerability from the study rather than risking tointroduce imprecisions. RQ : Approximations due to identifying bug-inducing com-mits using the SZZ algorithm [79] . We used heuristics tolimit the number of false positives, for example excludingblank and comment lines from the set of bug-inducing changes.Also, we computed both the minimum and the maximumsurvivability estimates on the basis of the SZZ outcome,showing that in any case the main outcome of our studydid not change: Android-related vulnerabilities survive forlong time. Moreover, the manual analysis performed on somevulnerabilities confirmed the validity of our experimental designto assess the survivability of vulnerabilities. RQ : Imprecision due to tangled code changes [80] . Wecannot exclude that some vulnerability-fixing commits groupedtogether tangled code changes, of which just a subset wasfocusing on the vulnerability fix. This would result in impreci-sions when running the SZZ algorithm on the fixing commit.Again, by presenting both the minimum and the maximumsurvivability estimates such a risk is mitigated.Threats to internal validity concern external factors wedid not consider that could affect the variables and the relations being investigated. When analysing the survivabilityof vulnerabilities (RQ ) we considered the severity of thevulnerability as a confounding factor to be controlled.We are aware that many other factors could influence thesurvivability, and we plan to analyze them in future work. Toreinforce the internal validity, when possible, we integrated thequantitative analysis with a qualitative one.Threats to conclusion validity concern the relation betweenthe treatment and the outcome. Although this is mainly anobservational study, wherever possible we used an appropriatesupport of statistical procedures, integrated with effect sizemeasures that, besides the significance of the differences found,highlight the magnitude of such differences.Threats to external validity concern the generalization ofresults. In RQ and RQ we considered 660 vulnerabilities,while the RQ ’s findings are based on the analysis of 201vulnerabilities due to the need for identifying the vulnerability-fixing commit (see Section III-A for details). Clearly, thenumber of Android-related vulnerabilities that can be studiedwill increase in the future, and larger replications of our studywill be possible.VI. C ONCLUSION AND F UTURE W ORK
We analyzed 660 Android-related vulnerabilities from threedifferent perspectives: (i) the types of the vulnerabilities andtheir hierarchical relationships, (ii) the layers and componentsfrom the Android software stack impacted by the vulnerabilities,and (iii) the survivability of the vulnerabilities ( i.e., the timerequired to fix a vulnerability since its introduction).The achieved results show that most of the vulnerabilitiesare related to improper restriction of operations in the boundsof memory buffers, issues processing data ( e.g., numeric, type,and string errors), improper access control, and improper inputvalidations. This suggests that most of the vulnerabilities canbe avoided by relying on secure coding practices especiallyin the context of data handling and memory access/allocation.Such practices could be enforced, for example, via just-in-time quality control techniques statically analyzing the codecontributed to the Android OS in each commit activity. Also,mobile OS developers could consider the usage of modernprogramming languages embedding mechanisms promotingsecure coding ( e.g.,
Rust [81]).Our findings also indicate that third-party hardware driversare the components mostly affected by security vulnerabilitiesin the Android OS, thus suggesting the strengthening ofverification & validation activities performed on them.Finally, we showed that Android vulnerabilities survive forlong time in the code base. This stresses the importance forresearchers to invest effort in the development of automaticvulnerability detectors tailored for the mobile world. Thetaxonomy of vulnerabilities presented in this paper can be usedas a reference for the definition of the types of vulnerabilitiessuch detectors should target. The design and implementationof effective vulnerability detection tools for mobile OS/apps ispart of our future research agenda.
ICSE’15 , 2015, pp. 725–728.[Online]. Available: http://dl.acm.org/citation.cfm?id=2819009.2819149[11] H. Bagheri, A. Sadeghi, J. Garcia, and S. Malek, “Covert: Compositionalanalysis of android inter-app permission leakage,”
IEEE Transactions onSoftware Engineering , vol. 41, no. 9, pp. 866–886, Sept 2015.[12] W. Ahmad, C. Kästner, J. Sunshine, and J. Aldrich, “Inter-appcommunication in android: Developer challenges,” in
Proceedings ofthe 13th International Conference on Mining Software Repositories , ser.MSR ’16. New York, NY, USA: ACM, 2016, pp. 177–188. [Online].Available: http://doi.acm.org/10.1145/2901739.2901762[13] D. R. Thomas,
The Lifetime of Android API Vulnerabilities: CaseStudy on the JavaScript-to-Java Interface (Transcript of Discussion) .Cham: Springer International Publishing, 2015, pp. 139–144. [Online].Available: http://dx.doi.org/10.1007/978-3-319-26096-9_14[14] D. R. Thomas, A. R. Beresford, and A. Rice, “Security metrics forthe android ecosystem,” in
Proceedings of the 5th Annual ACM CCSWorkshop on Security and Privacy in Smartphones and Mobile Devices ,ser. SPSM ’15. New York, NY, USA: ACM, 2015, pp. 87–98. [Online].Available: http://doi.acm.org/10.1145/2808117.2808118[15] M. Jimenez, M. Papadakis, T. F. Bissyandé, and J. Klein, “Profilingandroid vulnerabilities,” in , Aug 2016, pp. 222–229.[16] H. Bagheri, E. Kang, S. Malek, and D. Jackson, “A formal approach fordetection of security flaws in the android permission system,”
SpringerJournal on Formal Aspects of Computing , In Press.[17] C. Cao, N. Gao, P. Liu, and J. Xiang, “Towards analyzing the inputvalidation vulnerabilities associated with android system services,”in
Proceedings of the 31st Annual Computer Security ApplicationsConference , ser. ACSAC 2015. New York, NY, USA: ACM, 2015,pp. 361–370. [Online]. Available: http://doi.acm.org/10.1145/2818000.2818033[18] NIST. Nvd data feeds. http://nvd.nist.gov/download.cfm
Android Hacker’s Handbook . John Wiley and Sons,2014.[22] H. Huang, S. Zhu, K. Chen, and P. Liu, “From system servicesfreezing to system server shutdown in android: All you need is a loopin an app,” in
Proceedings of the 22Nd ACM SIGSAC Conferenceon Computer and Communications Security , ser. CCS ’15. NewYork, NY, USA: ACM, 2015, pp. 1236–1247. [Online]. Available:http://doi.acm.org/10.1145/2810103.2813606[23] Wikipedia. Heartbleed. https://en.wikipedia.org/wiki/Heartbleed.[24] Google. Android security 2015 year in review. https://static.googleusercontent.com/media/source.android.com/en//security/reports/Google_Android_Security_2015_Report_Final.pdf.[25] M. Xu, C. Song, Y. Ji, M.-W. Shih, K. Lu, C. Zheng, R. Duan, Y. Jang,B. Lee, C. Qian, S. Lee, and T. Kim, “Toward engineering a secureandroid ecosystem: A survey of existing techniques,”
ACM Comput. Surv. , vol. 49, no. 2, pp. 38:1–38:47, Aug. 2016. [Online]. Available:http://doi.acm.org/10.1145/2963145[26] W. You, B. Liang, W. Shi, S. Zhu, P. Wang, S. Xie, andX. Zhang, “Reference hijacking: Patching, protecting and analyzing onunmodified and non-rooted android devices,” in
Proceedings of the38th International Conference on Software Engineering , ser. ICSE ’16.New York, NY, USA: ACM, 2016, pp. 959–970. [Online]. Available:http://doi.acm.org/10.1145/2884781.2884863[27] K. Wang, Y. Zhang, and P. Liu, “Call me back!: Attacks onsystem server and system apps in android through synchronouscallback,” in
Proceedings of the 2016 ACM SIGSAC Conferenceon Computer and Communications Security , ser. CCS ’16. NewYork, NY, USA: ACM, 2016, pp. 92–103. [Online]. Available:http://doi.acm.org/10.1145/2976749.2978342[28] L. Wu, M. Grace, Y. Zhou, C. Wu, and X. Jiang, “The impact of vendorcustomizations on android security,” in
Proceedings of the 2013 ACMSIGSAC Conference on Computer & , ser.CCS ’13. New York, NY, USA: ACM, 2013, pp. 623–634. [Online].Available: http://doi.acm.org/10.1145/2508859.2516728[29] Y. Zhou and X. Jiang, “Dissecting android malware: Characterizationand evolution,” in , May2012, pp. 95–109.[30] Sufatrio, D. J. J. Tan, T.-W. Chua, and V. L. L. Thing, “Securingandroid: A survey, taxonomy, and challenges,”
ACM Comput. Surv. ,vol. 47, no. 4, pp. 58:1–58:45, May 2015. [Online]. Available:http://doi.acm.org/10.1145/2733306[31] A. Sadeghi, H. Bagheri, J. Garcia, and s. Malek, “A taxonomy and qualita-tive comparison of program analysis techniques for security assessment ofandroid software,”
IEEE Transactions on Software Engineering , vol. PP,no. 99, pp. 1–1, 2016.[32] S. Fahl, M. Harbach, T. Muders, L. Baumgärtner, B. Freisleben,and M. Smith, “Why eve and mallory love android: An analysisof android ssl (in)security,” in
Proceedings of the 2012 ACMConference on Computer and Communications Security , ser. CCS ’12.New York, NY, USA: ACM, 2012, pp. 50–61. [Online]. Available:http://doi.acm.org/10.1145/2382196.2382205[33] C. Zuo, J. Wu, and S. Guo, “Automatically detecting ssl error-handlingvulnerabilities in hybrid mobile web apps,” in
Proceedings of the10th ACM Symposium on Information, Computer and CommunicationsSecurity , ser. ASIA CCS ’15. New York, NY, USA: ACM, 2015, pp. 591–596. [Online]. Available: http://doi.acm.org/10.1145/2714576.2714583[34] M. Backes, S. Bugiel, and E. Derr, “Reliable third-party library detectionin android and its security applications,” in
Proceedings of the 2016ACM SIGSAC Conference on Computer and Communications Security ,ser. CCS ’16. New York, NY, USA: ACM, 2016, pp. 356–367.[Online]. Available: http://doi.acm.org/10.1145/2976749.2978333[35] D. Kantola, E. Chin, W. He, and D. Wagner, “Reducing attack surfacesfor intra-application communication in android,” in
Proceedings of theSecond ACM Workshop on Security and Privacy in Smartphones andMobile Devices , ser. SPSM ’12. New York, NY, USA: ACM, 2012, pp.69–80. [Online]. Available: http://doi.acm.org/10.1145/2381934.2381948[36] D. Sbîrlea, M. G. Burke, S. Guarnieri, M. Pistoia, and V. Sarkar,“Automatic detection of inter-application permission leaks in androidapplications,”
IBM J. Res. Dev. , vol. 57, no. 6, pp. 2:10–2:10, Nov.2013. [Online]. Available: http://dx.doi.org/10.1147/JRD.2013.2284403[37] W. Gasior and L. Yang, “Exploring covert channel in android platform,”in , Dec 2012, pp.173–177.[38] E. Novak, Y. Tang, Z. Hao, Q. Li, and Y. Zhang, “Physical media covertchannels on smart mobile devices,” in
Proceedings of the 2015 ACMInternational Joint Conference on Pervasive and Ubiquitous Computing ,ser. UbiComp ’15. New York, NY, USA: ACM, 2015, pp. 367–378.[Online]. Available: http://doi.acm.org/10.1145/2750858.2804253[39] W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung, P. McDaniel, and A. N.Sheth, “Taintdroid: An information-flow tracking system for realtimeprivacy monitoring on smartphones,” in
Proceedings of the 9th USENIXConference on Operating Systems Design and Implementation , ser.OSDI’10. Berkeley, CA, USA: USENIX Association, 2010, pp. 393–407.[Online]. Available: http://dl.acm.org/citation.cfm?id=1924943.1924971[40] S. Arzt, S. Rasthofer, C. Fritz, E. Bodden, A. Bartel, J. Klein,Y. Le Traon, D. Octeau, and P. McDaniel, “Flowdroid: Precise context,flow, field, object-sensitive and lifecycle-aware taint analysis for androidapps,” in
Proceedings of the 35th ACM SIGPLAN Conference onProgramming Language Design and Implementation , ser. PLDI ’14.ew York, NY, USA: ACM, 2014, pp. 259–269. [Online]. Available: http://doi.acm.org.ezproxy.uniandes.edu.co:8080/10.1145/2594291.2594299[41] V. Avdiienko, K. Kuznetsov, A. Gorla, A. Zeller, S. Arzt, S. Rasthofer,and E. Bodden, “Mining apps for abnormal usage of sensitive data,” in
ICSE’15 . [Online]. Available: http://dl.acm.org/citation.cfm?id=2818754.2818808[42] A. Gorla, I. Tavecchia, F. Gross, and A. Zeller, “Checking app behavioragainst app descriptions,” in
ICSE’14 , 2014, pp. 1025–1035. [Online].Available: http://doi.acm.org/10.1145/2568225.2568276[43] J. H. Castellanos, T. Wuchner, M. Ochoa, and S. Rueda, “Q-floid: Androidmalware detection with quantitative data flow graphs,” in
SingaporeCyber-Security Conference (SG-CRC) . IOS Press, 2016, pp. 13–26.[44] P. Gilbert, B.-G. Chun, L. P. Cox, and J. Jung, “Vision: Automatedsecurity validation of mobile apps at app markets,” in
Proceedings ofthe Second International Workshop on Mobile Cloud Computing andServices
Proceedings of the 8th WorkingConference on Mining Software Repositories , ser. MSR ’11. NewYork, NY, USA: ACM, 2011, pp. 93–102. [Online]. Available:http://doi.acm.org/10.1145/1985441.1985457[47] S. Lal and A. Sureka, “Comparison of seven bug report types: A case-study of google chrome browser project,” in
Proceedings of the 2005 International Workshop on MiningSoftware Repositories , 2005.[54] L. Moonen, “Generating robust parsers using island grammars,” in
Reverse Engineering, 2001. Proceedings. Eighth Working Conference on ,2001, pp. 13–22.[55] L. V. Hedges and I. Olkin,
Statistical Methods for Meta-Analysis .Academic Press, 1985.[56] G. Cumming,
Introduction to the New Statistics:Effect Sizes, ConfidenceIntervals, and Meta-Analysis . Routledge, 2011.[57] W. J. Conover,
Practical Nonparametric Statistics , 3rd ed. Wiley, 1998.[58] S. Holm, “A simple sequentially rejective Bonferroni test procedure,”
Scandinavian Journal on Statistics , vol. 6, pp. 65–70, 1979. [59] R. J. Grissom and J. J. Kim,
Effect sizes for research: A broad practicalapproach , 2nd ed. Lawrence Earlbaum Associates, 2005.[60] MITRE. Cwe-703: Improper check or handling of exceptional conditions.https://cwe.mitre.org/data/definitions/703.html.[61] ——. Cwe-284: Improper access control. https://cwe.mitre.org/data/definitions/284.html.[62] ——. Cwe-640: Weak password recovery mechanism for forgottenpassword. https://cwe.mitre.org/data/definitions/640.html.[63] ——. Cwe-465: Pointer issues. https://cwe.mitre.org/data/definitions/465.html.[64] ——. Cwe-120: Buffer copy without checking size of input (’classicbuffer overflow’). https://cwe.mitre.org/data/definitions/120.html.[65] ——. Cwe-121: Stack-based buffer overflow. https://cwe.mitre.org/data/definitions/121.html.[66] ——. Cwe-122: Heap-based buffer overflow. https://cwe.mitre.org/data/definitions/122.html.[67] ——. Cwe-190: Integer overflow or wraparound. https://cwe.mitre.org/data/definitions/190.html.[68] ——. Cwe-787: Out-of-bounds write.https://cwe.mitre.org/data/definitions/787.html.[69] ——. Cwe-201: Information exposure through sent data. https://cwe.mitre.org/data/definitions/201.html.[70] ——. Cwe-94: Improper control of generation of code (’code injection’).https://cwe.mitre.org/data/definitions/94.html.[71] ——. Cwe-275: Permission issues. https://cwe.mitre.org/data/definitions/275.html.[72] ——. Cwe-840: Business logic errors. https://cwe.mitre.org/data/definitions/840.html.[73] ——. Cwe-862: Missing authorization. https://cwe.mitre.org/data/definitions/862.html.[74] ——. Cwe-327: Use of a broken or risky cryptographic algorithm. https://cwe.mitre.org/data/definitions/327.html.[75] R. Christensen,
Plane Answers to Complex Questions: The Theory ofLinear Models , fouth ed., ser. Springer Texts in Statistics. Springer,2011.[76] Aosp commit cf1581c66c2ad8c5b1aaca2e43e350cf5974f46d. http://tinyurl.com/hxqdp7f.[77] Aosp commit edd4a76eb4747bd19ed122df46fa46b452c12a0d. http://tinyurl.com/hkw399d.[78] Aosp commit 8ec845c8fe0f03bc57c901bc484541bdd6a7cf80. http://tinyurl.com/hvndh7r.[79] S. Kim, E. J. W. Jr., and Y. Zhang, “Classifying software changes: Cleanor buggy?”
IEEE Transactions on Software Engineering , vol. 34, no. 2,pp. 181–196, 2008.[80] K. Herzig and A. Zeller, “The impact of tangled code changes,” in