Dartmouth College Dartmouth Digital Commons Dartmouth College Ph.D Dissertations Theses and Dissertations 4-1-2018 Types for the Chain of Trust: No (Loader) Write Left Behind Rebecca Shapiro Dartmouth College Follow this and additional works at: https://digitalcommons.dartmouth.edu/dissertations Part of the Computer Sciences Commons Recommended Citation Shapiro, Rebecca, "Types for the Chain of Trust: No (Loader) Write Left Behind" (2018). Dartmouth College Ph.D Dissertations. 56. https://digitalcommons.dartmouth.edu/dissertations/56 This Thesis (Ph.D.) is brought to you for free and open access by the Theses and Dissertations at Dartmouth Digital Commons. It has been accepted for inclusion in Dartmouth College Ph.D Dissertations by an authorized administrator of Dartmouth Digital Commons. For more information, please contact [email protected]. TYPES FOR THE CHAIN OF TRUST: NO (LOADER) WRITE LEFT BEHIND Dartmouth Computer Science Technical Report TR2018-863 A Thesis Submitted to the Faculty in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Science by Rebecca “.bx” Shapiro DARTMOUTH COLLEGE Hanover, New Hampshire April, 2018 Examining Committee: (chair) Sergey Bratus, Ph.D. (co-chair) Sean W. Smith, Ph.D. Devin Balkcom, Ph.D. Greg Morrisett, Ph.D. F. Jon Kull, Ph.D. Dean of Graduate Studies Abstract The software chain of trust starts with a chain of loaders. Software is just as reliant on the sequence of loaders that ultimately setup its runtime environment as it is on the libraries with which it shares its address space and offloads tasks onto. Loaders, and especially bootloaders, act as the keystone of trust, and yet their formal security properties – which should be a part of any solid bootloader design – are both underap- preciated and not well understood. This is especially problematic given the increasing adoption of loader-based code signing and execution enforcement mechanisms. My thesis digs deeply into how loaders have failed to earn our trustworthiness and how they may continue to harbor vulnerabilities even after memory corruption-based vul- nerabilities lose their prevalence. In order to address these issues, I propose a memory region-based type system that allows us to better model a loader’s intentions and thus mediate its behavior. More specifically, I show how a loader’s execution canbe broken down into a sequence of typed phases, each semantically classified as either a bookkeeping, loading, or a patching substage, while sections of memory are grouped into semantically related regions and assigned a type, based on their intended use, by which policy access decisions are made. I demonstrate the feasibility of this technique by applying it to Das U-Boot, a well-known and widely-used bootloader, with minimal changes to the bootloader’s implementation. In order to do so, I designed and devel- oped an extensive bootloader instrumentation suite to help analyze a bootloader’s behaviors, construct a policy, and completely mediate operations, thereby enforcing behaviors governed by the type system’s policy. ii There is no moment in life that can’t be improved with pizza. –Daria Morgendorffer, from MTV’s Daria Acknowledgments I owe a great deal of gratitude to my advisor, Sergey Bratus, for his guidance and patience. Anya Shubina, who played a much grater role in my PhD research than she may even realize. My committee for their insightful advice and direction. Travis Goodspeed and the Scooby Crew along with the generations of trust labbies all who have played a non-trivial role in the generation of this thesis. The Wellesley computer science department faculty and its few (but mighty) computer science students who charmed me into taking my first computer science classes so I could be captivated by its shiny puzzles and enchanting mysteries. My family and friends for their support and patience. Also, all those yaks I shaved in the creation of this thesis (none which were harmed). And you, the reader, even if you are not explicitly listed here, for endeavoring to drink from the fire hose that is this dissertation. iii Contents Abstract ii Acknowledgments iii Contents iv List of Figures ix List of Tables xi 1 Introduction 1 1.1 Our trust in bootloaders ......................... 3 1.2 A different perspective on bootloader design .............. 5 1.2.1 Loader safety properties ..................... 5 1.2.2 Designing a safe bootloader ................... 7 1.3 Contributions ............................... 8 2 Loaders and their vulnerabilities 10 2.1 A loader’s onus .............................. 12 2.1.1 The evolution of loaders ..................... 13 2.1.2 Loader safety properties ..................... 16 2.1.3 Properties of an address space: a loader’s opus . 16 2.2 Loader vulnerabilities ........................... 18 2.2.1 Code signing ........................... 18 iv 2.2.2 Out-of-bounds memory accesses . 19 2.3 i$DEVICES/iOS bootloader vulnerabilities . 21 2.3.1 iOS boot sequence overview ................... 21 2.3.2 Bootloader image format and storage . 22 2.3.3 The baseband (modem) boot process . 23 2.3.4 Type overlap loading weaknesses . 24 2.3.5 Loader enforcement/verification failures . 28 2.4 Loader vulnerabilities beyond iOS .................... 29 2.4.1 Android phone loader vulnerabilities . 30 2.4.2 UEFI ............................... 30 2.4.3 Game Consoles .......................... 31 2.4.4 BIOS ............................... 31 2.4.5 Everything else .......................... 32 2.5 The language of loading ......................... 32 3 Obstacles to loader analysis 35 3.1 Loader metadata and questionable behaviors . 35 3.1.1 ELF metadata: accidentally Turing-complete . 36 3.1.2 An ELF metadata-based root shell . 38 3.1.3 A Mach-O metadata root shell . 40 3.1.4 A PE metadata-driven packer . 43 3.1.5 Loader metadata-based parser differentials . 43 3.2 Reining in a loader ............................ 44 3.2.1 Implementation considerations . 44 3.2.2 Runtime environment ...................... 52 3.3 Final remarks ............................... 52 4 Bootloader instrumentation and analysis 54 v 4.1 Bootloader instrumentation techniques . 56 4.1.1 Bare metal debugging ...................... 56 4.1.2 Emulation-based debugging ................... 58 4.2 Dynamic bootloader analysis ....................... 59 4.3 Dynamically tracking memory writes . 59 4.3.1 Watchpoints ........................... 59 4.3.2 Breakpoints ............................ 60 4.3.3 Memory-mapped registers .................... 62 4.3.4 Relocation ............................. 63 4.4 Data collection and analysis ....................... 64 4.4.1 Dynamic call graph generation . 65 4.5 Related firmware instrumentation work . 68 4.6 Bootloader static analysis ........................ 68 5 Access properties & region typing 71 5.1 Mew-Boot on a ManulBoard: a toy system . 73 5.1.1 ManulBoard hardware description . 73 5.1.2 Initial ManulBoard memory layout . 74 5.1.3 Mew-Boot bootloader description . 74 5.1.4 ManulBoard/Mew-Boot vs. BeagleBoard-xM/U-Boot . 77 5.2 Address region-based write access control . 77 5.2.1 RBWAC definition ........................ 78 5.2.2 Substages ............................. 81 5.2.3 Bootloader design patterns ................... 83 5.2.4 Substage transitions ....................... 87 5.2.5 Region typing ........................... 89 5.2.6 Policy violations ......................... 92 5.2.7 Policy rules and logic ....................... 95 vi 5.3 RBWACµ sample policy instances .................... 95 5.3.1 Basic ManulBoard policy .................... 97 5.3.2 A more complex ManulBoard policy . 98 5.4 Retrofitting an RBWACµ instance .................... 99 5.4.1 Bootloader reconnaissance and substage extraction . 102 5.5 BBxM U-Boot SPL RBWACµ policy . 114 5.5.1 BBxM substage and region definitions . 117 5.5.2 BBxM SPL’s policy architecture . 119 5.6 RBWACµ policy language . 126 5.6.1 Region definitions . 126 5.6.2 Substage definitions and region type transitions . 129 5.7 RBWACµ instance and enforcement challenges . 131 5.7.1 Addressing challenges via static analysis . 136 5.7.2 Addressing changes via rearchitecting the system . 139 5.8 Other applications of RBWAC . 139 6 Future directions 141 6.1 Theory ................................... 141 6.2 Performance ................................ 142 6.3 “It’s not a bus, it’s a network!” . 143 6.4 Other tangentially-related research questions . 144 7 Conclusion 145 7.1 Concluding thoughts . 145 7.2 Final thoughts .............................. 147 A RBWAC-inspired U-Boot discoveries 149 A.1 BBxM hardware and documentation . 149 A.1.1 Documentation’s register tables . 149 vii A.1.2 ARM TrustZone security extensions . 150 A.2 QEMU ................................... 151 A.3 U-Boot ................................... 154 A.3.1 Code bloat ............................ 154 A.3.2 Undefined registers . 156 A.3.3 Typing issues . 156 A.3.4 Linkmap scripts and tricks . 157 B Loader-related vulnerabilities 158 C U-Boot Frama-C value analysis 165 C.1 Running a Frama-C analysis on U-Boot . 165 C.1.1 Frama-C value analysis statistics . 165 C.1.2 Frama-C ARM architecture support . 166 C.1.3 U-Boot source code post-preprocessing tool . 166 C.1.4 U-Boot assembly code . 167 C.1.5 Alignment issues . 171 C.1.6 Static linker-generated structures . 171 C.1.7 Recursion ............................. 171 C.1.8 Frama-C execution options . 172 C.2 Frama-C destination analysis plugin source . 173 C.3 ARM architecture definition for Frama-C . 177 C.4 C representation of U-Boot assembly code . 178 C.5 Frama-C source code patch . 184 D BBxM U-Boot SPL RBWAC policy definition 185 D.1 Region definitions ............................. 185 D.2 Substage definitions and region retyping rules . 189 D.3 U-Boot source code ............................ 191 viii Bibliography 209 List of Figures 1.1 Instances of secure boot adoption since 2010 .............. 4 2.1 Front panel of PDP-11/70 computer . 15 2.2 iOS boot stages and image storage locations . 23 2.3 Mach-O loading commands ....................... 33 3.1 Root shell-backdoor in ELF ping .................... 40 3.2 Root shell-backdoor in Mach-O ping .