Bootstomp: on the Security of Bootloaders in Mobile Devices
Total Page：16
File Type：pdf, Size：1020Kb
BootStomp: On the Security of Bootloaders in Mobile Devices Nilo Redini, Aravind Machiry, Dipanjan Das, Yanick Fratantonio, Antonio Bianchi, Eric Gustafson, Yan Shoshitaishvili, Christopher Kruegel, and Giovanni Vigna, UC Santa Barbara https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/redini This paper is included in the Proceedings of the 26th USENIX Security Symposium August 16–18, 2017 • Vancouver, BC, Canada ISBN 978-1-931971-40-9 Open access to the Proceedings of the 26th USENIX Security Symposium is sponsored by USENIX BootStomp: On the Security of Bootloaders in Mobile Devices Nilo Redini, Aravind Machiry, Dipanjan Das, Yanick Fratantonio, Antonio Bianchi, Eric Gustafson, Yan Shoshitaishvili, Christopher Kruegel, and Giovanni Vigna fnredini, machiry, dipanjan, yanick, antoniob, edg, yans, chris, [email protected] University of California, Santa Barbara Abstract by proposing simple mitigation steps that can be im- plemented by manufacturers to safeguard the bootloader Modern mobile bootloaders play an important role in and OS from all of the discovered attacks, using already- both the function and the security of the device. They deployed hardware features. help ensure the Chain of Trust (CoT), where each stage of the boot process verifies the integrity and origin of 1 Introduction the following stage before executing it. This process, in theory, should be immune even to attackers gaining With the critical importance of the integrity of today’s full control over the operating system, and should pre- mobile and embedded devices, vendors have imple- vent persistent compromise of a device’s CoT. However, mented a string of inter-dependent mechanisms aimed at not only do these bootloaders necessarily need to take removing the possibility of persistent compromise from untrusted input from an attacker in control of the OS in the device. Known as “Trusted Boot” [6] or “Verified the process of performing their function, but also many Boot,” [8], these mechanisms rely on the idea of a Chain of their verification steps can be disabled (“unlocked”) to of Trust (CoT) to validate each component the system allow for development and user customization. Apply- loads as it begins executing code. Ideally, this proce- ing traditional analyses on bootloaders is problematic, as dure can verify cryptographically that each stage, from hardware dependencies hinder dynamic analysis, and the a Hardware Root of Trust through the device’s file sys- size, complexity, and opacity of the code involved pre- tem, is both unmodified and authorized by the hardware’s clude the usage of many previous techniques. manufacturer. Any unverified modification of the various In this paper, we explore vulnerabilities in both the bootloader components, system kernel, or file system im- design and implementation of mobile bootloaders. We age should result in the device being rendered unusable examine bootloaders from four popular manufacturers, until a valid one can be restored. and discuss the standards and design principles that they Ideally, this is an uncircumventable, rigid process, re- strive to achieve. We then propose BOOTSTOMP, a moving any possibility of compromise, even when at- multi-tag taint analysis resulting from a novel combina- tackers can achieve arbitrary code execution on the high- tion of static analyses and dynamic symbolic execution, level operating system (e.g., Android or iOS). However, designed to locate problematic areas where input from an hardware vendors are given a great amount of discretion attacker in control of the OS can compromise the boot- when implementing these bootloaders, leading to varia- loader’s execution, or its security features. Using our tions in both the security properties they enforce and the tool, we find six previously-unknown vulnerabilities (of size of the attack surface available to an adversary. which five have been confirmed by the respective ven- Unfortunately, analyzing the code of bootloaders to dors), as well as rediscover one that had been previously- locate vulnerabilities represents a worst-case scenario reported. Some of these vulnerabilities would allow an for security analysts. Bootloaders are typically closed- attacker to execute arbitrary code as part of the boot- source [21], proprietary programs, and tend to lack loader (thus compromising the entire chain of trust), or typical metadata (such as program headers or debug- to perform permanent denial-of-service attacks. Our tool ging symbols) found in normal programs. By their also identified two bootloader vulnerabilities that can be very nature, bootloaders are tightly coupled with hard- leveraged by an attacker with root privileges on the OS ware, making dynamic analysis outside of the often- to unlock the device and break the CoT. We conclude uncooperative target platform impractical. Manual USENIX Association 26th USENIX Security Symposium 781 reverse-engineering is also very complicated, as boot- abilities (which could lead to persistent compromise loaders typically do not use system calls or well-known of the device) as well as two unlock-bypass vulner- libraries, leaving few semantic hints for an analyst to fol- abilities. low. • We propose mitigations against such attacks, which In this paper, we first explore the security properties, are trivial to retrofit into existing implementations. implementations, and weaknesses of today’s mobile de- In the spirit of open science, we make our analysis tool vice bootloaders. We begin with a discussion of the 1 proposed standards and guidelines a secure bootloader publicly available to the community . should possess, and what, instead, is left to the discretion of manufacturers. We then showcase four real-world An- 2 Bootloaders in Theory droid bootloader implementations on the market today. Then, we present a static analysis approach, imple- Today’s mobile devices incorporate a number of secu- mented in a tool called BOOTSTOMP, which uses a novel rity features aimed at safeguarding the confidentiality, combination of static analysis techniques and under- integrity, and availability of users’ devices and data. In constrained symbolic execution to build a multi-tag taint this section, we will discuss Trusted Execution Environ- analysis capable of identifying bootloader vulnerabili- ments, which allow for isolated execution of privileged ties. Our tool highlighted 36 potentially dangerous paths, code, and Trusted Boot, aimed at ensuring the integrity and, for 38.3% of them, we found actual vulnerabilities. and provenance of code, both inside and outside of TEEs. In particular, we were able to identify six previously- unknown vulnerabilities (five of them already confirmed by the vendors), as well as rediscover one that had been 2.1 TEEs and TrustZone previously-reported (CVE-2014-9798). Some of these vulnerabilities would allow an adversary with root privi- A Trusted Execution Environment (TEE) is the notion leges on the Android OS to execute arbitrary code as part of separating the execution of security-critical (“trusted”) of the bootloader. This compromises the entire chain of code from that of the traditional operating system (“un- trust, enabling malicious capabilities such as access to trusted”) code. Ideally, this isolation is enforced using the code and storage normally restricted to TrustZone, hardware, such that even in the event the un-trusted OS and to perform permanent denial-of-service attacks (i.e., is completely compromised, the data and code in the TEE device bricking). Our tool also identified two bootload- remain unaffected. ers that can be unlocked by an attacker with root privi- Modern ARM processors, found in almost all mobile leges on the OS. phones sold today, implement TrustZone[1], which pro- We finally propose a modification to existing, vulner- vides a TEE with hardware isolation enforced by the ar- able bootloaders, which can quickly and easily protect chitecture. When booted, the primary CPU creates two them from any similar vulnerabilities due to compromise “worlds”–known as the “secure” world and “non-secure” of the high-level OS. These changes leverage hardware world, loads the un-trusted OS (such as Android) into the features already present in mobile devices today and, non-secure world, and a vendor-specific trusted OS into when combined with recommendations from Google [8] the secure world. The trusted OS provides various cryp- and ARM [6], enforce the least-privilege principle, dra- tographic services, guards access to privileged hardware, matically constraining the attack surface of bootloaders and, in recent implementations, can be used to verify the and allowing for easier verification of the few remaining integrity of the un-trusted OS while it is running. The un- attackable components. trusted kernel accesses these commands by issuing the In summary, our contributions are as follows: Secure Monitor Call (SMC) instruction, which both trig- • We perform a study of popular bootloaders present gers the world-switch operation, and submits a command on mobile devices, and compare the security proper- the Trusted OS and its services should execute. ties they implement with those suggested by ARM ARM Exception Levels (EL). In addition to being in and Google. either the secure or non-secure world, ARM processors • We develop a novel combination of program anal- support “Exception Levels,” which define the amount of ysis techniques, including static analysis as well privilege to various registers and hardware features the as symbolic execution, to detect