Whack-A-Mole Security: Incentivising the Production, Delivery and Installation of Security Updates Alastair R. Beresford Computer Laboratory, University of Cambridge arb33@cam.ac.uk Whack-a-mole security works when vulnerabilities are discovered by good netizens, such as penetration Abstract testers, anti-virus vendors and academics, who report the vulnerabilities to the appropriate software vendors. Writing vulnerability-free code is currently Software vendors then produce an update and send impossible. The best we can hope for is whack- it to all affected devices before a potential attacker a-mole security. In other words, fixing bugs discovers the vulnerability and uses it for malice. and updating Internet-enabled devices before Failures occur for two reasons: firstly, attackers ex- remote exploitation occurs. Unfortunately, ploit vulnerabilities before good netizens find them security updates do not always happen in a (zero-day exploits); secondly, software updates from timely fashion, or at all. The root cause of vendors do not arrive before attackers exploit a vul- this problem is the lack of incentives, some- nerability found by a good netizen. thing which we must fix. There is good academic literature on exploits, both on how they are found and how they work. There Introduction is also excellent work looking at reducing the likeli- Many computers today, from servers to laptops, and hood of introducing vulnerabilities in the first place. from tablets to smartphones are connected to the In- There is much less work on whether software vendors ternet. Connectivity is an essential feature of these actually patch vulnerabilities however. As a research platforms. Over the next few years, the rise of the In- community we should do more in this space. ternet of Things (IoT) will see many more embedded computers connected to the Internet too. Everything An example: the Android ecosystem from heating controllers to lightbulbs will be online. Unfortunately, connecting computers to the Inter- We have looked at the Android ecosystem in order net does not just provide essential functionality, but to determine if Android smartphones receive security also enables remote attack. Yet we rely on many updates. What we found was worrying—from July of our Internet-enabled devices to operate correctly. 2011 until July 2015, 87.7% of Android devices were This state of affairs occurs because we cannot write vulnerable to at least one of 11 critical vulnerabili- vulnerability-free software. We cannot even provide ties [TBR15]. In this case, the problem occurs be- reasonable guarantees of software correctness when de- cause handset manufacturers are not producing secu- veloping complex, feature-rich software for a reason- rity updates. Analysis of the Android Open Source able price. What, then, can we do? Current best Project, and Google Nexus devices reveals that Google practice is whack-a-mole security: in other words, de- does regularly produce fixes for disclosed vulnerabili- vices are secured by patching latent vulnerabilities in ties. When updates do appear for devices, data from software after their discovery, but before exploitation. our Device Analyzer [WRB13] project shows that up- dates are installed by users across many different mo- Copyright c by the paper’s authors. Copying permitted for bile network operators, suggesting that the network private and academic purposes. This volume is published and operators are providing the updates, and users are in- copyrighted by its editors. stalling them. In: D. Aspinall, L. Cavallaro, M. N. Seghir, M. Volkamer (eds.): Proceedings of the Workshop on Innovations in Mobile Note that in this analysis we have quantified the Privacy and Security IMPS at ESSoS’16, London, UK, 06-April- proportion of devices which are at risk of attack. We 2016, published at http://ceur-ws.org have not yet measured the harm which might follow 9 1 through exploitation. publish detailed results. This makes it hard for con- For the Android ecosystem, the cost of producing sumers or regulators to make informed choices based the fix is non-trivial and manufacturers are economi- on data. In the cryptographic sphere, Certificate cally incentivised to spend valuable engineering time Transparency [Lau14] shows great promise, because on producing new models, not fixing older ones which it produces an auditable public log. Auditable pub- generate little or no future revenue. To address this, lic logs can be applied to software updates too. This we need to develop better measures of both risk and would allow us to track the progress (or not) of updates harm. And we need to provide better incentives to from software vendors, through network operators and manufacturers through accreditation, through regula- on towards installation by individuals. Note that there tion, and through awareness raising with consumers is a potential privacy conflict here—the update status and corporate buyers. of devices may implicitly leak some personal data. It is also important to distinguish between risk and The anatomy of an update harm. Estimating the potential future harm from risk is a difficult process which deserves more attention. It’s not just operating systems which require updates. Finally, quantifying the ability of software vendors All layers of the stack, including apps themselves, re- to whack their security moles is not enough. We need quire updates to fix vulnerabilities. For example, Fahl to improve incentives. This can take a variety of forms, et al. found that 8% of Android apps examined con- including presenting appropriate data to the public, tained SSL/TLS code which was vulnerable to man- as well as to corporations and governments. Better in-the-middle attacks [FHM+ 12]. As part of an under- regulation is also likely to be important. graduate project, we found the same vulnerabilities in many apps on the Google Play store two years later. Acknowledgements Incentivising developers to fix apps is, in some ways, harder than fixing operating systems because there are Huge thanks to my collaborators Daniel R. Thomas many more app developers than smartphone handset and Andrew Rice on Android vulnerabilities, and Gra- manufacturers, many of whom are individuals or small ham Edgecombe for his work analysing Android apps. companies with limited resources and less expertise. The issue of managing updates extends beyond soft- References ware, since the security of Internet-connected devices [FHM+ 12] Sascha Fahl, Marian Harbach, Thomas has a basis in cryptography, which in turn requires Muders, Lars Baumgärtner, Bernd managing updates to key material. Indeed, the in- Freisleben, and Matthew Smith. Why Eve tegrity of updates to operating systems and apps is and Mallory love Android: An analysis of protected by cryptography. At the extreme, in the Android SSL (in) security. In Proceedings case of JavaScript running in a browser, an update to of the ACM conference on Computer and the software may be performed on every page load. Communications Security, pages 50–61. Similarly, in the case of TLS, a server may present a ACM, 2012. new certificate on every connection establishment, or even during the lifetime of a single connection. [Lau14] Ben Laurie. Certificate Transparency. Since we are unable to write vulnerability-free soft- Queue, 12(8):10, 2014. ware, keys can, and are, compromised. Therefore de- [OS06] Andy Ozment and Stuart E. Schechter. vices will need to securely update keys too. Milk or wine: does software security im- prove with age? In Usenix Security, 2006. The solution space [TBR15] Daniel R. Thomas, Alastair R. Beresford, The rate at which security vulnerabilities are found and Andrew Rice. Security metrics for the in a stable code base may reduce over time [OS06], android ecosystem. In Proceedings of the which offers some hope for IoT systems whose feature ACM CCS Workshop on Security and Pri- set might be small and does not necessarily need to vacy in Smartphones and Mobile Devices, change. This is unlikely to be a popular solution for pages 87–98. ACM, 2015. smartphones or laptops since a vibrant ecosystem de- mands new apps, new hardware and new operating [WRB13] Daniel T. Wagner, Andrew Rice, and Alas- system features regularly. (So called feature creep may tair R. Beresford. Device analyzer: Under- turn out to be a requirement in the IoT space too.) standing smartphone usage. In Mobile and Auditing of software by independent third-parties Ubiquitous Systems: Computing, Network- is useful. Google Play and Apple’s App Store do this ing, and Services, pages 195–208. Springer, for apps, although unfortunately they do not often 2013. 10 2