By Daniel Carter, Daniel Thomas, and Alastair Beresford
Security updates are an important mechanism for protecting users and their devices from attack, and therefore it’s important vendors produce security updates, and that users apply them. Producing security updates is particularly difficult when more than one vendor needs to make changes in order to secure a system.
We studied one such example in previous research (open access). The specific vulnerability (CVE-2012-6636) affected Android devices and allowed JavaScript running inside a WebView of an app (e.g. an advert) to run arbitrary code inside the app itself, with all the permissions of app. The vulnerability could be exploited remotely by an attacker who bought ads which supported JavaScript. In addition, since most ads at the time were served over HTTP, the vulnerability could also be exploited if an attacker controlled a network used by the Android device (e.g. WiFi in a coffee shop). The fix required both the Android operating system, and all apps installed on the handset, to support at least Android API Level 17. Thus, the deployment of an effective solution for users was especially challenging.
When we published our paper in 2015, we predicted that this vulnerability would not be patched on 95% of devices in the Android ecosystem until January 2018 (plus or minus a standard deviation of 1.23 years). Since this date has now passed, we decided to check whether our prediction was correct.
To perform our analysis we used data on deployed API versions taken from (almost) monthly snapshots of Google’s Android Distribution Dashboard which we have been tracking. The good news is that we found the operating system update requirements crossed the 95% threshold in May 2017, seven months earlier than our best estimate, and within one standard deviation of our prediction. The most recent data for May 2019 shows deployment has reached 98.2% of devices in use. Nevertheless, fixing this aspect of the vulnerability took well over 4 years to reach 95% of devices.
Google delivered a further fix in Android 4.4.3 that blocked access to the getClass method from JavaScript, considerably reducing the risk of exploitation even from apps which were not updated. A conservative estimate of the deployment of this further fix is shown on the graph, reaching 95% adoption in April 2019. On the app side of things, Google has also been encouraging app developers to update. From 1st November 2018, updates to apps on Google Play must target API level 26 or higher and from November 1st 2019 updates to apps must target API level 28 or higher. This change forces the app-side changes necessary to fix this vulnerability. Unfortunately we don’t have good data on the distribution of apps installed on handsets, but we expect that most Android devices are now secure against this vulnerability.
Our work is not done however, and we are still looking into the security of mobile devices. This summer we are extending the work from our other 2015 paper Security Metrics for the Android Ecosystem where we analysed the composition of Android vulnerabilities. Last time we used distributions of deployed Android versions on devices from Device Analyzer (an Android measurement app we deployed to Google Play), the device management system of a FTSE 100 company, and User-Agent string data from an ISP in Rwanda. If you might be able to share similar data with us to support our latest research work then please get in touch: contact@androidvulnerabilities.org.