1 00:00:00,000 --> 00:00:14,825 *34c3 intro* 2 00:00:14,825 --> 00:00:18,970 Herald: This is Audrey from California and 3 00:00:18,970 --> 00:00:26,820 she's from the University of California Santa Barbara, security lab, if I'm 4 00:00:26,820 --> 00:00:38,109 informed correctly, and it is about automated discovery of vulnerabilities in 5 00:00:38,109 --> 00:00:50,999 the Android bootloader. Wow, not really my problem but definitely Audrey's. So here 6 00:00:50,999 --> 00:00:57,492 we go. Please let's have a big hand for Audrey Dutcher. Thank you. 7 00:00:57,492 --> 00:01:07,040 *applause* 8 00:01:07,040 --> 00:01:11,050 Audrey: Good evening everybody. Today 9 00:01:11,050 --> 00:01:17,330 we're talking about Android boot loaders. As a brief aside I didn't actually work on 10 00:01:17,330 --> 00:01:21,790 this work I just sit across from the people who worked on this work and I was 11 00:01:21,790 --> 00:01:26,659 the only one who could make it to Germany. I have, do work on some of the stuff that 12 00:01:26,659 --> 00:01:32,189 it depends on, so this is my field but this is not my project. Just brief 13 00:01:32,189 --> 00:01:41,010 disclaimer, thanks. So today we're talking about Android boot loaders. Phones are 14 00:01:41,010 --> 00:01:45,929 complicated, bootloaders are complicated, processors are complicated and trying to 15 00:01:45,929 --> 00:01:50,740 get at the bottom of these is very difficult subject; if you ever done any 16 00:01:50,740 --> 00:01:55,299 homebrew kernel dev or homebrew retro- gaming, you know that interacting with 17 00:01:55,299 --> 00:01:59,530 hardware is really complicated and trying to do this in a phone, a system connected 18 00:01:59,530 --> 00:02:03,749 to a touchscreen and a modem and lots of complicated, money sensitive things, it's 19 00:02:03,749 --> 00:02:10,580 really not, it's really complicated and - but every single one of you has one of has 20 00:02:10,580 --> 00:02:15,840 probably has a phone in your pocket and all of these are immensely valuable 21 00:02:15,840 --> 00:02:21,500 targets for attacks, so we want to be able to *inhales* detect bugs in them 22 00:02:21,500 --> 00:02:27,220 automatically, that's the name of the game. So the bootloader in a device: it 23 00:02:27,220 --> 00:02:31,810 takes - it's the it's the job of "oh, we've powered on, we need to get 24 00:02:31,810 --> 00:02:37,890 everything initialized", so we initialize the device and the peripherals and then 25 00:02:37,890 --> 00:02:43,680 the final the final gasp of breath of the bootloader is to take the kernel and 26 00:02:43,680 --> 00:02:49,120 execute it. And the kernel obviously needs to be loaded from storage somewhere. For 27 00:02:49,120 --> 00:02:53,830 Android specifically, this is what we worked, on most Android devices are ARMs, 28 00:02:53,830 --> 00:02:56,830 there's no particular standard for what an ARM bootloader should look like but the 29 00:02:56,830 --> 00:02:59,910 ARM people do give you some guidelines. There's an open-source implementation of 30 00:02:59,910 --> 00:03:04,040 what a secure boot letter should look like. There are in fact several boot 31 00:03:04,040 --> 00:03:08,660 loaders on ARM, we'll go over this later. But it's some mor- it's a complicated 32 00:03:08,660 --> 00:03:14,380 affair that needs to preserve several security properties along the way. And 33 00:03:14,380 --> 00:03:19,010 above all, the whole goal of this process is to make sure that things are secure and 34 00:03:19,010 --> 00:03:26,050 to make sure the user data is protected. That's what we're trying to do. Like we 35 00:03:26,050 --> 00:03:31,170 said the phones in your pockets are valuable targets. If you can attack the 36 00:03:31,170 --> 00:03:34,870 bootloader you can root you can roo- get a rootkit on the device, which is even more 37 00:03:34,870 --> 00:03:40,451 powerful than just getting root on it. If an attacker were to compromised your phone 38 00:03:40,451 --> 00:03:45,720 he could brick your device or establi- I talked about rootkits already but but 39 00:03:45,720 --> 00:03:50,890 additionally you might want to circumvent the security properties of your phone's 40 00:03:50,890 --> 00:03:56,930 bootloader in order to customize it: rooting, jailbreaking. "Unlocking" is the 41 00:03:56,930 --> 00:04:04,530 key word in this situation. The Android bootloader establishes 42 00:04:04,530 --> 00:04:10,650 cryptographic integrity over basically what's happening at all times, so on your 43 00:04:10,650 --> 00:04:17,450 phone there is a master key and that will, that kno- that knows that it should only 44 00:04:17,450 --> 00:04:21,399 it should only run some code that has been signed with the key associated with the 45 00:04:21,399 --> 00:04:24,940 hardware and then the next stage of bootloader has a key that it will verify 46 00:04:24,940 --> 00:04:28,500 that the next stage of the bootloader hasn't been tampered with. And this is 47 00:04:28,500 --> 00:04:34,160 where we get the term "chain of trust", where each part establishes "oh, I'm very 48 00:04:34,160 --> 00:04:38,720 very sure, cryptographically sure, assuming RSA hasn't been broken yet, that 49 00:04:38,720 --> 00:04:44,570 the next bit of code is going to be doing something that I authorized." 50 00:04:44,570 --> 00:04:48,940 Circumventing this is valuable, as we've talked about, phones have to have a way to 51 00:04:48,940 --> 00:04:56,470 buil- to do that built-in, unless you're Apple, and but obviously protecting this 52 00:04:56,470 --> 00:05:02,600 mechanism from attackers is a point of contention, so really you need to make 53 00:05:02,600 --> 00:05:10,211 sure that only the real owner of the device can actually unlock the phone. So 54 00:05:10,211 --> 00:05:16,400 wha- this project is about making is about discovering vulnerabilities that let us 55 00:05:16,400 --> 00:05:20,110 circumvent this process, so the threat model that we use for this project is that 56 00:05:20,110 --> 00:05:25,320 there is, the phone is rooted and the attacker has this root control. This is 57 00:05:25,320 --> 00:05:32,060 pretty out there, no not that out there, root vulnerabilities exist, but it's it's 58 00:05:32,060 --> 00:05:35,720 enough to make you scoff "Oh what's the point of this", well, the security 59 00:05:35,720 --> 00:05:39,920 properties of the phone are supposed to extend above the hypervisor level. It's, 60 00:05:39,920 --> 00:05:42,430 you're supposed to have these guarantees that things should always work, assuming 61 00:05:42,430 --> 00:05:47,513 the chain of trust works, regardless of what how what's happening in the kernel. 62 00:05:48,940 --> 00:05:54,650 So today we are going to be talking about BootStomp, which is a tool that 63 00:05:54,650 --> 00:05:59,600 automatically verifies these properties and discovers bugs. I'm going a little 64 00:05:59,600 --> 00:06:04,310 slow, I'll speed up. So first of the booting process in Android 65 00:06:04,310 --> 00:06:09,080 ecosystems is pretty complicated and multi-stage; there is the there's the base 66 00:06:09,080 --> 00:06:13,250 bootloader BL1, which loads and verifies another bootloader, which loads and 67 00:06:13,250 --> 00:06:17,260 verifies another bootloader and this is important, because the first on's in a ROM 68 00:06:17,260 --> 00:06:22,710 and is very small and the second one is probably going, is probably by the 69 00:06:22,710 --> 00:06:27,260 hardware vendor and the third one is probably by the OS vendor, for example, 70 00:06:27,260 --> 00:06:33,250 and they all need to do different things. So the important part here is these EL 71 00:06:33,250 --> 00:06:37,389 things; those are the ARM exception levels, which are basically the global 72 00:06:37,389 --> 00:06:42,300 permission levels for an android processor. The EL3 is basically the god 73 00:06:42,300 --> 00:06:45,500 mode. There's EL2 for hypervisors, it isn't in this chart, there's EL1, which is 74 00:06:45,500 --> 00:06:50,790 the kernel and the EL0, which is user space. So when we boot you're obviously in 75 00:06:50,790 --> 00:06:53,772 the highest execution level and gradually, as we establish more and more 76 00:06:53,772 --> 00:06:59,200 initialization of the device, we're going to cede control to less privileged 77 00:06:59,200 --> 00:07:04,949 components, so the bootloader is operate very privilegededly and one of the things 78 00:07:04,949 --> 00:07:10,630 they need to do is establish what's, the ARM trust zone, the trusted execution 79 00:07:10,630 --> 00:07:18,610 environment that lets people do really secure things on Android phones. 80 00:07:18,610 --> 00:07:25,710 That's, this is something that is set up by built by the BL31 bootloader and in 81 00:07:25,710 --> 00:07:29,270 secure world you need to do things like establish, initialize hardware and 82 00:07:29,270 --> 00:07:34,040 peripherals and in the non secure world you're norm- you're running like the 83 00:07:34,040 --> 00:07:38,570 normal kernel and the normal users apps. And on some phones you actually have a 84 00:07:38,570 --> 00:07:45,699 final bootloader, which runs in EL1, BL33 or the aboot executable and that's the 85 00:07:45,699 --> 00:07:52,910 that's the one that we're generally targeting for for this stuff. So this is 86 00:07:52,910 --> 00:07:55,690 what I was talking about the chain of trust: each of those arrows represents 87 00:07:55,690 --> 00:08:00,360 cryptographic integrity, so the next stage only gets loaded if there's a valid 88 00:08:00,360 --> 00:08:09,420 signature indicating that we really trust what's going on here. And that's the 89 00:08:09,420 --> 00:08:13,729 unlocking process that we were talking about; if you, the verified, physical 90 00:08:13,729 --> 00:08:18,210 owner of the device, wants to you can disable that last bit and cause and allow 91 00:08:18,210 --> 00:08:21,889 untrusted code to run as the kernel. That's totally fine, if you own the 92 00:08:21,889 --> 00:08:27,770 device. The unlocking process is supposed to 93 00:08:27,770 --> 00:08:30,850 really specifically verify these two things: that you have physical access to 94 00:08:30,850 --> 00:08:37,799 the device and that you actually own it, like you know the pin to it, that's what 95 00:08:37,799 --> 00:08:46,050 establishes ownership of our device.And so specifically when you when you go through 96 00:08:46,050 --> 00:08:51,430 that process it does set some specific flags on your persistent storage, saying 97 00:08:51,430 --> 00:08:57,569 this is an unlocked device now, you can do whatever but making sure that that can 98 00:08:57,569 --> 00:09:05,009 only happen when it's authorized is the point of contention here. It should, the, 99 00:09:05,009 --> 00:09:09,449 typically what happens is this security state is itself cryptographically signed, 100 00:09:09,449 --> 00:09:15,100 so you can't just set unlocked, you have to set unlocked but signed by the people 101 00:09:15,100 --> 00:09:22,529 that we really trust. And but but generally you probably shouldn't be able 102 00:09:22,529 --> 00:09:30,899 to write to it just from the normal user space. So the question is: we saw that the 103 00:09:30,899 --> 00:09:34,940 operating system is separate from the bootloader. So what we want to be able to 104 00:09:34,940 --> 00:09:40,119 do is get from the Android OS to affecting the, to the bootloader. And can this 105 00:09:40,119 --> 00:09:48,139 happen? Well, of course, that's why we're here. So the, let's see. Oh I didn't 106 00:09:48,139 --> 00:09:52,470 realize there were animations on the slides, that's unfortunate. So this is 107 00:09:52,470 --> 00:09:59,420 sort of the normal flow chart of how these things normally come about. 108 00:09:59,420 --> 00:10:03,589 You've got the bootloader, which has to read from persistent storage in order to 109 00:10:03,589 --> 00:10:07,459 initialize the operating system. Like, of course you have to read, for example, 110 00:10:07,459 --> 00:10:11,139 whether or not the device is unlocked, you have to load the kernel itself. There are 111 00:10:11,139 --> 00:10:17,009 lots of inputs to the bootloader and intuition is that the bootloader is, these 112 00:10:17,009 --> 00:10:22,550 just serve as normal inputs to a program, which can be analyzed for vulnerabilities. 113 00:10:22,550 --> 00:10:30,869 Oh lord, this is a mess. So so from the OS, you're allowed to, you ha- if you have 114 00:10:30,869 --> 00:10:35,880 root privileges in the operating system you can write to this persistent storage, 115 00:10:35,880 --> 00:10:46,920 which means that you have that this serves as another input to the bootloader and 116 00:10:46,920 --> 00:10:53,180 this can cause bad things to happen. So we need some sort of tool, it's the point of 117 00:10:53,180 --> 00:10:58,189 this project, to automatically verify the safety properties of these boot loaders. 118 00:10:58,189 --> 00:11:04,481 That's BootStomp. Bootloaders are complicated. There's a lot of stuff, which 119 00:11:04,481 --> 00:11:08,480 means you have to automate - the analysis has to be automated in order to really 120 00:11:08,480 --> 00:11:11,999 sift through something as big and complicated as a bootloader, with the care 121 00:11:11,999 --> 00:11:16,860 necessary to actually find bugs that are sitting there. 122 00:11:16,860 --> 00:11:20,310 And but these things aren't usually things that you have source code for, so it needs 123 00:11:20,310 --> 00:11:25,420 to be a binary analysis and furthermore you can't really do a dynamic execution on 124 00:11:25,420 --> 00:11:29,679 something that needs to run on the highest privilege level of a processor, so you 125 00:11:29,679 --> 00:11:33,389 have to have your - step back - and it has to be static as well. And furthermore this 126 00:11:33,389 --> 00:11:37,499 needs to be a fully free-standing analysis that doesn't assume anything other than 127 00:11:37,499 --> 00:11:42,080 "oh, we're executing code on a system", because there's no known syscalls or API's 128 00:11:42,080 --> 00:11:46,959 to checkpoint process or say "oh, we know what this means, we don't really have to 129 00:11:46,959 --> 00:11:56,069 analyze it." So it's a tall order but you can do it with enough work. So BootStomp 130 00:11:56,069 --> 00:12:02,970 specifically is the tool that we built. It will automatically detect these inputs, 131 00:12:02,970 --> 00:12:09,870 that we talked about, to the bootloader and then it will determine if these inputs 132 00:12:09,870 --> 00:12:14,050 can be used to compromise various security properties of the device. 133 00:12:14,050 --> 00:12:20,050 One such example is if you can use this to just achieve memory corruption for example 134 00:12:20,050 --> 00:12:27,649 or more abstract forms of vulnerability, such as code flows that will result in 135 00:12:27,649 --> 00:12:33,319 unwanted data being written by the more privileged bootloader somewhere. And the 136 00:12:33,319 --> 00:12:39,519 important thing about this analysis is that its results are easily verifiable and 137 00:12:39,519 --> 00:12:44,970 traceable and it's very easy to like look at the outputs and say "oh, well, this is 138 00:12:44,970 --> 00:12:48,579 what's happening and this is why I think this happened and therefore I can 139 00:12:48,579 --> 00:12:59,290 reproduce this, possibly?" This happens through symbolic taint analysis. This is 140 00:12:59,290 --> 00:13:05,550 the part that I know about, because I work on angr, which is the symbolic execution 141 00:13:05,550 --> 00:13:11,209 analysis static analysis tool that bootstomp uses in order to do its taint 142 00:13:11,209 --> 00:13:18,910 analysis. That taint analysis of all execution are kind of loaded words, so 143 00:13:18,910 --> 00:13:24,259 this is what specifically is meant is that when we discover these sources and sinks 144 00:13:24,259 --> 00:13:28,790 of behavior, through person particularly static static analysis and some 145 00:13:28,790 --> 00:13:32,040 heuristics, of course. And then we propagate these taints through symbolic 146 00:13:32,040 --> 00:13:35,319 execution, while maintaining tractability. And notice wherever 147 00:13:35,319 --> 00:13:39,850 we meet wherever we can find pause from taint sources to behaviors sinks that we 148 00:13:39,850 --> 00:13:47,420 think are vulnerable. Specifically, we think these these behavior sinks are 149 00:13:47,420 --> 00:13:51,889 vulnerable behavior if you can arbitrarily write to memory, or read from memory. 150 00:13:51,889 --> 00:13:55,040 Like, really arbitrary, if there's a pointer which is controlled by user input 151 00:13:55,040 --> 00:13:59,980 - memory corruption stuff. And additionally, if you can control loop 152 00:13:59,980 --> 00:14:04,449 iterations through your input, that indicates the denial of service attack. 153 00:14:04,449 --> 00:14:11,820 And finally, the unlocking mechanism, the bootloader unlocking mechanism, if there 154 00:14:11,820 --> 00:14:18,269 is if we can detect specific code paths which indicate bypasses - those are 155 00:14:18,269 --> 00:14:25,910 valuable. So, yeah, so this is the specific architecture of the tool. There 156 00:14:25,910 --> 00:14:31,290 are the two main modules one which is written as an IDA analysis. You know, the 157 00:14:31,290 --> 00:14:35,209 big tool that everyone probably doesn't pay enough money for. And then there's the 158 00:14:35,209 --> 00:14:41,829 other component written in angr which is the symbolic change analysis. And this is 159 00:14:41,829 --> 00:14:51,850 probably the point where I break out of here and actually start the live demo. 160 00:14:51,850 --> 00:14:58,671 That's big enough. Okay, so we're working on a Huawei boot 161 00:14:58,671 --> 00:15:07,100 image here, the fastboot image. We're going to load it up in IDA real quick. So 162 00:15:07,100 --> 00:15:14,689 here, IDA has understands, oh this is what the executable is. So if we just sort of 163 00:15:14,689 --> 00:15:23,819 run the initial script, find taints, it'll think real hard for a little bit. There's 164 00:15:23,819 --> 00:15:27,199 no real reason this couldn't if it's part couldn't have been done an angr or binary 165 00:15:27,199 --> 00:15:33,579 ninja or r2 or (???), god forbid. But, this is a collaborative project if you saw 166 00:15:33,579 --> 00:15:36,970 the huge author list and people write stuff and whatever they're comfortable 167 00:15:36,970 --> 00:15:41,859 with. So it's IDA in this case. Realistically, because this is just a 168 00:15:41,859 --> 00:15:46,839 binary blob when you load it in IDA it doesn't immediately know where everything 169 00:15:46,839 --> 00:15:54,469 is, so you have to sort of nudge it into.. oh here's where all the functions are. 170 00:15:54,469 --> 00:16:05,399 Okay, we finished, and what it's done is: we've got this taint source sync dot txt 171 00:16:05,399 --> 00:16:12,229 which shows us, "oh, here are all the sources of tainted information, and here's a few of 172 00:16:12,229 --> 00:16:16,459 the sinks that we established." Obviously you don't need a sink analysis to 173 00:16:16,459 --> 00:16:20,119 determine if you've got memory corruption or not but we like knowing where the 174 00:16:20,119 --> 00:16:23,809 writes to persistent storage are and where all the specifically the memcopy functions 175 00:16:23,809 --> 00:16:35,209 are valuable for analysis. And then, if we run our taint analysis bootloader, taint 176 00:16:35,209 --> 00:16:38,759 on the - oh this configuration file is real simple. It just says, "oh here's what 177 00:16:38,759 --> 00:16:42,040 we're analyzing: it's a 64-bit architecture, don't bother analyzing thumb 178 00:16:42,040 --> 00:16:51,989 mode, etc cetera, simple stuff." And it'll do this for about 20 minutes. Uh, config; 179 00:16:51,989 --> 00:16:57,629 and it'll do this for about 20 minutes. I hope it finishes before the demo is over. 180 00:16:57,629 --> 00:17:05,779 If not, I'll do some magic and we'll a pre-prepared solution. But, so, we talked 181 00:17:05,779 --> 00:17:09,579 about these seeds there used the the seeds for our taint analysis or for our 182 00:17:09,579 --> 00:17:17,500 persistent storage. And that I used by the unlocking procedure. So the heuristics I 183 00:17:17,500 --> 00:17:21,369 was talking about - we want to identify the reads from persistent storage through 184 00:17:21,369 --> 00:17:26,050 log messages, keyword keyword analysis and long distances. So the eMMC is this is a 185 00:17:26,050 --> 00:17:29,689 specific memory module used by the bootloader for secure purposes. And 186 00:17:29,689 --> 00:17:34,809 just it's the persistent storage device basically. And you can identify these log 187 00:17:34,809 --> 00:17:39,500 messages and then we just do a diff -u analysis back from the guard condition on 188 00:17:39,500 --> 00:17:44,330 that block to its source and you say, "oh that function must be the read." It's 189 00:17:44,330 --> 00:17:52,149 pretty simple. It works surprisingly often. Of course, if this isn't enough you 190 00:17:52,149 --> 00:17:56,320 can just manually analyze the firmware and provide, "oh here's where we read from 191 00:17:56,320 --> 00:17:58,171 persistent storage, here's what you should taint." 192 00:18:07,900 --> 00:18:11,600 Cool. So the taint 193 00:18:11,600 --> 00:18:15,200 analysis: our taints are specifically sy-- this is specifically symbolic taint 194 00:18:15,200 --> 00:18:19,809 analysis so it's not just like what Triton does where you've got a concrete value 195 00:18:19,809 --> 00:18:25,160 that has metadata attached. This is a real symbol being used for symbolic execution. 196 00:18:25,160 --> 00:18:29,799 If you're not familiar with symbolic execution, it's a if it's a form of static 197 00:18:29,799 --> 00:18:38,330 analysis in which you emulate the code, but instead of having the values for some 198 00:18:38,330 --> 00:18:41,169 of things you can just have symbols. And then when you perform operation on those 199 00:18:41,169 --> 00:18:46,450 symbols you construct an abstract syntax tree of the behavior. And then when you 200 00:18:46,450 --> 00:18:52,250 run into branch conditions based on those things you can say, "oh, well, in order to 201 00:18:52,250 --> 00:19:00,419 get from point A to point B this constraint must be satisfied." And of 202 00:19:00,419 --> 00:19:05,470 course, now you can just add z3 and stir and you have passed the inputs to generate 203 00:19:05,470 --> 00:19:12,230 paths to the program. So for the sinks of the taint analysis, we want we wants to 204 00:19:12,230 --> 00:19:18,960 say, "oh, if tainted data come comes into and is is the argument to memcpy then 205 00:19:18,960 --> 00:19:23,220 that's a vulnerability." I don't mean like, it's the I don't mean like, the 206 00:19:23,220 --> 00:19:28,059 taint data is the subject of memcopy, like it's one of the values passed to memcpy. 207 00:19:28,059 --> 00:19:33,549 That's a memory corruption vulnerability generally. Yeah, we talked about memory 208 00:19:33,549 --> 00:19:36,409 corruption, and we talked about loop conditions, and we talked about writes to 209 00:19:36,409 --> 00:19:41,220 persistent storage with the unlocking stuff. Cool. For taint checking 210 00:19:41,220 --> 00:19:46,429 specifically -- oh this is exactly what I just said. Yeah, and part and what I was 211 00:19:46,429 --> 00:19:50,480 talking about with the symbolic predicates and trace analysis means 212 00:19:50,480 --> 00:19:54,130 that when you see something, you automatically have 213 00:19:54,130 --> 00:20:00,350 the input that will generate that behavior. So the output is inherently 214 00:20:00,350 --> 00:20:06,169 traceable. Unfortunately, symbolic execution has some issues. I was actually 215 00:20:06,169 --> 00:20:12,380 at CCC two years ago talking about the exact same problem. You have this problem 216 00:20:12,380 --> 00:20:18,759 where, oh, you generate paths between different between different states and 217 00:20:18,759 --> 00:20:24,210 there can be too many of them. It overwhelms your analysis. So you can use 218 00:20:24,210 --> 00:20:29,269 some heuristics to say, "oh, we don't want to we can; because it's the static 219 00:20:29,269 --> 00:20:34,050 analysis we have a more powerful step over than what a debugger can do." We don't 220 00:20:34,050 --> 00:20:37,340 have to actually analyze the function, we can just take the instruction pointer and 221 00:20:37,340 --> 00:20:43,590 move it over there. And, this does cause some unsoundness, but it's not a problem 222 00:20:43,590 --> 00:20:49,039 if you like make sure that the arguments aren't tainted, for example. Or sometimes 223 00:20:49,039 --> 00:20:53,909 you just accept the unsoundness as part of the tractability of the problem. Limit 224 00:20:53,909 --> 00:20:58,519 loop operation: that's classic technique from static analysis. And the time out, of 225 00:20:58,519 --> 00:21:05,610 course. So, what are the bugs we found? We evaluated this on four boot loaders and we 226 00:21:05,610 --> 00:21:15,090 found several bugs. Six of which were zero days. So that's pretty good. It's like, 227 00:21:15,090 --> 00:21:18,980 okay, so you found some bugs but it could just be you; oh there are some errors and 228 00:21:18,980 --> 00:21:22,880 an initialization that don't really matter. But on the other hand you can 229 00:21:22,880 --> 00:21:31,669 crash it 41 41 41. That's pretty serious. So as we saw, some of the bootloader is 230 00:21:31,669 --> 00:21:35,710 like do work in ARM EL3 so this is pretty significant. You can do whatever you want 231 00:21:35,710 --> 00:21:39,919 in the device if you actually have sufficient control over it. This is 232 00:21:39,919 --> 00:21:47,669 rootkit territory. You could break anything you wanted. Then there's another 233 00:21:47,669 --> 00:21:52,120 component in the analysis that says, "can we'd find bypasses to the unlocking 234 00:21:52,120 --> 00:21:57,860 procedure." For example, this is this is basically one of the ones that we found: 235 00:21:57,860 --> 00:22:03,890 it's so it says boots on detected this, this flow from data that was read from the 236 00:22:03,890 --> 00:22:09,440 device to data that was written to the device, and what this code is supposed to 237 00:22:09,440 --> 00:22:12,880 do -- do I have animations? yes --it's supposed to, 238 00:22:12,880 --> 00:22:15,460 like, take some input and verify that it hashes 239 00:22:15,460 --> 00:22:20,130 to a certain value. And if so, hash that value and write it back to disk, and 240 00:22:20,130 --> 00:22:27,110 that constitutes the cryptographically secure unlocking thing. However, the thing 241 00:22:27,110 --> 00:22:32,740 that we write to is compared to the identical to the thing that was read from 242 00:22:32,740 --> 00:22:39,789 the disk. So you can just; the thing that boots on purported was the code flow from 243 00:22:39,789 --> 00:22:43,990 the disk backs the disk indicating that if you can read from the disk, you know how 244 00:22:43,990 --> 00:22:53,190 to produce the thing that will unlock the phone. So this isn't secure. Mitigations. 245 00:22:53,190 --> 00:22:59,440 So, the thing that Google does in order to prevent attacks of this class is that the 246 00:22:59,440 --> 00:23:04,419 key ness is the secure encryption key that unlocked, that decrypts the like userland 247 00:23:04,419 --> 00:23:13,460 data is, has embedded in it the unlock state. So clearly, if you change the 248 00:23:13,460 --> 00:23:17,460 unlock state you brick the entire phone. Well, not brick, but have to reset it have 249 00:23:17,460 --> 00:23:27,440 to lose all your data. That's still not really good enough but realistically we 250 00:23:27,440 --> 00:23:32,950 should probably be using a more trusted form of storage that's not just the normal 251 00:23:32,950 --> 00:23:36,809 normal partitions in the SD card in order to just sort of store this state. It 252 00:23:36,809 --> 00:23:41,490 should probably be part of the eMMC, or specifically the replay protected memory 253 00:23:41,490 --> 00:23:46,789 block which uses cryptographic mechanisms to synchronize the, what's it called, 254 00:23:46,789 --> 00:23:55,269 synchronize this writes to the memory with the authenticated process. And so that 255 00:23:55,269 --> 00:23:58,270 would make that would make sure that only the bootloader could unlock it. But 256 00:23:58,270 --> 00:24:01,789 of course that wouldn't protect against memory corruption vulnerabilities and 257 00:24:01,789 --> 00:24:04,780 there's nothing really to be said about that other than, "hey, this is a serious 258 00:24:04,780 --> 00:24:11,970 problem." In conclusion, all these bugs have been reported, most of them have been 259 00:24:11,970 --> 00:24:17,990 fixed. As far as I'm aware this is the first study to really explore and 260 00:24:17,990 --> 00:24:22,309 develop analyses for Android boot loaders and in it we developed an automated 261 00:24:22,309 --> 00:24:26,751 technique to analyze boot loaders with tractable alerts. I found six 0days in 262 00:24:26,751 --> 00:24:32,409 various boot loaders and our implementation is open source. I will be 263 00:24:32,409 --> 00:24:34,960 taking questions, thank you for listening. 264 00:24:34,960 --> 00:24:43,950 *applause* 265 00:24:43,950 --> 00:24:46,110 Herald: That was quite amazing. 266 00:24:49,770 --> 00:24:53,120 Okay we'll be taking some questions from people 267 00:24:53,120 --> 00:24:56,890 that understood exactly what it was all about. Yes 268 00:24:56,890 --> 00:24:59,110 I see somebody walking up to microphone one. 269 00:24:59,110 --> 00:25:02,390 Mic 1: Thank you very much for talk-- 270 00:25:02,390 --> 00:25:04,810 Herald: Are you talking the mic otherwise we can't record it. 271 00:25:04,810 --> 00:25:06,959 Mic 1: Okay, thank you very much for that 272 00:25:06,959 --> 00:25:11,659 work, that was really cool. Your mystic investigations didn't include devicing the 273 00:25:11,659 --> 00:25:16,289 code better. Do you think it's possible to write the code so that your tools can 274 00:25:16,289 --> 00:25:21,350 analyze it and maybe it would be secure? Or not yet? 275 00:25:21,350 --> 00:25:28,240 Audrey: Well, there's certainly things to be said for having things in open source, 276 00:25:28,240 --> 00:25:33,360 because necessarily doing analysis on source code is a much more, a much better 277 00:25:33,360 --> 00:25:41,250 defined field than the than doing analysis on binary code. Additionally, you can 278 00:25:41,250 --> 00:25:48,010 write your stuff in languages there is safer than C. I don't know if it's, I 279 00:25:48,010 --> 00:25:55,519 didn't know if it's safe to talk about rust yet, but rust is cool. Yeah, there's 280 00:25:55,519 --> 00:26:00,759 lots of things that you can do. I just realized I didn't show off; I didn't show 281 00:26:00,759 --> 00:26:05,820 off the still running, the analysis: the automated results. It did not finish in 282 00:26:05,820 --> 00:26:12,820 time so I will run some magic, and now we have some results. Which.. 283 00:26:12,820 --> 00:26:19,429 *applause* 284 00:26:19,429 --> 00:26:21,859 So, here's a here's one of the analysis 285 00:26:21,859 --> 00:26:27,519 results. We found at this location in the program a tainted variable, specifically 286 00:26:27,519 --> 00:26:33,049 the tainted at offset 261 into the tainted buffer. This variable was used as a 287 00:26:33,049 --> 00:26:41,019 pointer. And that involved following the path from along along this way. So there 288 00:26:41,019 --> 00:26:46,320 is a vulnerability that I discovered for you. So we can go on with question sorry that 289 00:26:46,320 --> 00:26:47,160 was a bit. 290 00:26:47,160 --> 00:26:48,619 Herald: Any more questions from the 291 00:26:48,619 --> 00:26:57,780 audience? There is no question from from the internet. Okay, one question, go 292 00:26:57,780 --> 00:27:00,029 ahead: talk into the mic please. 293 00:27:00,029 --> 00:27:03,029 Question: You said that the bugs you found 294 00:27:03,029 --> 00:27:07,789 where responsibly disclosed and fixed. Were they actually fixed in real existing 295 00:27:07,789 --> 00:27:11,860 devices or did the vendors just say, "oh, we'll fix it in future devices." 296 00:27:11,860 --> 00:27:16,759 Audrey: I wish I knew the answer to that question. I wasn't on the in the did this. 297 00:27:16,759 --> 00:27:23,100 Yeah, I can't speak to that. That was just that was just a slide on the slides that I 298 00:27:23,100 --> 00:27:29,780 was given. I sure hope they were really responsibly disclosed. It's real hard to 299 00:27:29,780 --> 00:27:36,400 push updates to the bootloader! 300 00:27:36,400 --> 00:27:39,960 Herald: Okay, any more questions? okay so 301 00:27:39,960 --> 00:27:43,909 let's conclude this talk. People, when you leave the hall, please take all your stuff 302 00:27:43,909 --> 00:27:49,554 with you. Your bottles, your cups. Don't forget anything, have a last check. Thank 303 00:27:49,556 --> 00:27:55,053 you very much let's have one final hand for Audrey Dutcher, from California! 304 00:27:55,053 --> 00:28:00,749 *applause* 305 00:28:00,749 --> 00:28:22,101 *34c3 outro*