=Paper=
{{Paper
|id=Vol-1575/invited_paper_1
|storemode=property
|title=Whack-A-Mole Security: Incentivising the Production, Delivery and Installation of Security Updates (invited paper)
|pdfUrl=https://ceur-ws.org/Vol-1575/invited_paper_1.pdf
|volume=Vol-1575
|authors=Alastair R. Beresford
|dblpUrl=https://dblp.org/rec/conf/essos/Beresford16
}}
==Whack-A-Mole Security: Incentivising the Production, Delivery and Installation of Security Updates (invited paper)==
https://ceur-ws.org/Vol-1575/invited_paper_1.pdf
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