WEBVTT
00:00:00.000 --> 00:00:14.825
34c3 intro
00:00:14.825 --> 00:00:18.970
Herald: This is Audrey from California and
00:00:18.970 --> 00:00:26.820
she's from the University of California
Santa Barbara, security lab, if I'm
00:00:26.820 --> 00:00:38.109
informed correctly, and it is about
automated discovery of vulnerabilities in
00:00:38.109 --> 00:00:50.999
the Android bootloader. Wow, not really my
problem but definitely Audrey's. So here
00:00:50.999 --> 00:00:57.492
we go. Please let's have a big hand for
Audrey Dutcher. Thank you.
00:00:57.492 --> 00:01:07.040
applause
00:01:07.040 --> 00:01:11.050
Audrey: Good evening everybody. Today
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
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
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
00:01:26.659 --> 00:01:32.189
it depends on, so this is my field but
this is not my project. Just brief
00:01:32.189 --> 00:01:41.010
disclaimer, thanks. So today we're talking
about Android boot loaders. Phones are
00:01:41.010 --> 00:01:45.929
complicated, bootloaders are complicated,
processors are complicated and trying to
00:01:45.929 --> 00:01:50.740
get at the bottom of these is very
difficult subject; if you ever done any
00:01:50.740 --> 00:01:55.299
homebrew kernel dev or homebrew retro-
gaming, you know that interacting with
00:01:55.299 --> 00:01:59.530
hardware is really complicated and trying
to do this in a phone, a system connected
00:01:59.530 --> 00:02:03.749
to a touchscreen and a modem and lots of
complicated, money sensitive things, it's
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
00:02:10.580 --> 00:02:15.840
probably has a phone in your pocket and
all of these are immensely valuable
00:02:15.840 --> 00:02:21.500
targets for attacks, so we want to be able
to inhales detect bugs in them
00:02:21.500 --> 00:02:27.220
automatically, that's the name of the
game. So the bootloader in a device: it
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
00:02:31.810 --> 00:02:37.890
everything initialized", so we initialize
the device and the peripherals and then
00:02:37.890 --> 00:02:43.680
the final the final gasp of breath of the
bootloader is to take the kernel and
00:02:43.680 --> 00:02:49.120
execute it. And the kernel obviously needs
to be loaded from storage somewhere. For
00:02:49.120 --> 00:02:53.830
Android specifically, this is what we
worked, on most Android devices are ARMs,
00:02:53.830 --> 00:02:56.830
there's no particular standard for what an
ARM bootloader should look like but the
00:02:56.830 --> 00:02:59.910
ARM people do give you some guidelines.
There's an open-source implementation of
00:02:59.910 --> 00:03:04.040
what a secure boot letter should look
like. There are in fact several boot
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
00:03:08.660 --> 00:03:14.380
affair that needs to preserve several
security properties along the way. And
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
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
00:03:26.050 --> 00:03:31.170
said the phones in your pockets are
valuable targets. If you can attack the
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
00:03:34.870 --> 00:03:40.451
powerful than just getting root on it. If
an attacker were to compromised your phone
00:03:40.451 --> 00:03:45.720
he could brick your device or establi- I
talked about rootkits already but but
00:03:45.720 --> 00:03:50.890
additionally you might want to circumvent
the security properties of your phone's
00:03:50.890 --> 00:03:56.930
bootloader in order to customize it:
rooting, jailbreaking. "Unlocking" is the
00:03:56.930 --> 00:04:04.530
key word in this situation.
The Android bootloader establishes
00:04:04.530 --> 00:04:10.650
cryptographic integrity over basically
what's happening at all times, so on your
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
00:04:17.450 --> 00:04:21.399
it should only run some code that has been
signed with the key associated with the
00:04:21.399 --> 00:04:24.940
hardware and then the next stage of
bootloader has a key that it will verify
00:04:24.940 --> 00:04:28.500
that the next stage of the bootloader
hasn't been tampered with. And this is
00:04:28.500 --> 00:04:34.160
where we get the term "chain of trust",
where each part establishes "oh, I'm very
00:04:34.160 --> 00:04:38.720
very sure, cryptographically sure,
assuming RSA hasn't been broken yet, that
00:04:38.720 --> 00:04:44.570
the next bit of code is going to be doing
something that I authorized."
00:04:44.570 --> 00:04:48.940
Circumventing this is valuable, as we've
talked about, phones have to have a way to
00:04:48.940 --> 00:04:56.470
buil- to do that built-in, unless you're
Apple, and but obviously protecting this
00:04:56.470 --> 00:05:02.600
mechanism from attackers is a point of
contention, so really you need to make
00:05:02.600 --> 00:05:10.211
sure that only the real owner of the
device can actually unlock the phone. So
00:05:10.211 --> 00:05:16.400
wha- this project is about making is about
discovering vulnerabilities that let us
00:05:16.400 --> 00:05:20.110
circumvent this process, so the threat
model that we use for this project is that
00:05:20.110 --> 00:05:25.320
there is, the phone is rooted and the
attacker has this root control. This is
00:05:25.320 --> 00:05:32.060
pretty out there, no not that out there,
root vulnerabilities exist, but it's it's
00:05:32.060 --> 00:05:35.720
enough to make you scoff "Oh what's the
point of this", well, the security
00:05:35.720 --> 00:05:39.920
properties of the phone are supposed to
extend above the hypervisor level. It's,
00:05:39.920 --> 00:05:42.430
you're supposed to have these guarantees
that things should always work, assuming
00:05:42.430 --> 00:05:47.513
the chain of trust works, regardless of
what how what's happening in the kernel.
00:05:48.940 --> 00:05:54.650
So today we are going to be talking about
BootStomp, which is a tool that
00:05:54.650 --> 00:05:59.600
automatically verifies these properties
and discovers bugs. I'm going a little
00:05:59.600 --> 00:06:04.310
slow, I'll speed up.
So first of the booting process in Android
00:06:04.310 --> 00:06:09.080
ecosystems is pretty complicated and
multi-stage; there is the there's the base
00:06:09.080 --> 00:06:13.250
bootloader BL1, which loads and verifies
another bootloader, which loads and
00:06:13.250 --> 00:06:17.260
verifies another bootloader and this is
important, because the first on's in a ROM
00:06:17.260 --> 00:06:22.710
and is very small and the second one is
probably going, is probably by the
00:06:22.710 --> 00:06:27.260
hardware vendor and the third one is
probably by the OS vendor, for example,
00:06:27.260 --> 00:06:33.250
and they all need to do different things.
So the important part here is these EL
00:06:33.250 --> 00:06:37.389
things; those are the ARM exception
levels, which are basically the global
00:06:37.389 --> 00:06:42.300
permission levels for an android
processor. The EL3 is basically the god
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
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
00:06:50.790 --> 00:06:53.772
the highest execution level and gradually,
as we establish more and more
00:06:53.772 --> 00:06:59.200
initialization of the device, we're going
to cede control to less privileged
00:06:59.200 --> 00:07:04.949
components, so the bootloader is operate
very privilegededly and one of the things
00:07:04.949 --> 00:07:10.630
they need to do is establish what's, the
ARM trust zone, the trusted execution
00:07:10.630 --> 00:07:18.610
environment that lets people do really
secure things on Android phones.
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
00:07:25.710 --> 00:07:29.270
secure world you need to do things like
establish, initialize hardware and
00:07:29.270 --> 00:07:34.040
peripherals and in the non secure world
you're norm- you're running like the
00:07:34.040 --> 00:07:38.570
normal kernel and the normal users apps.
And on some phones you actually have a
00:07:38.570 --> 00:07:45.699
final bootloader, which runs in EL1, BL33
or the aboot executable and that's the
00:07:45.699 --> 00:07:52.910
that's the one that we're generally
targeting for for this stuff. So this is
00:07:52.910 --> 00:07:55.690
what I was talking about the chain of
trust: each of those arrows represents
00:07:55.690 --> 00:08:00.360
cryptographic integrity, so the next stage
only gets loaded if there's a valid
00:08:00.360 --> 00:08:09.420
signature indicating that we really trust
what's going on here. And that's the
00:08:09.420 --> 00:08:13.729
unlocking process that we were talking
about; if you, the verified, physical
00:08:13.729 --> 00:08:18.210
owner of the device, wants to you can
disable that last bit and cause and allow
00:08:18.210 --> 00:08:21.889
untrusted code to run as the kernel.
That's totally fine, if you own the
00:08:21.889 --> 00:08:27.770
device.
The unlocking process is supposed to
00:08:27.770 --> 00:08:30.850
really specifically verify these two
things: that you have physical access to
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
00:08:37.799 --> 00:08:46.050
establishes ownership of our device.And so
specifically when you when you go through
00:08:46.050 --> 00:08:51.430
that process it does set some specific
flags on your persistent storage, saying
00:08:51.430 --> 00:08:57.569
this is an unlocked device now, you can do
whatever but making sure that that can
00:08:57.569 --> 00:09:05.009
only happen when it's authorized is the
point of contention here. It should, the,
00:09:05.009 --> 00:09:09.449
typically what happens is this security
state is itself cryptographically signed,
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
00:09:15.100 --> 00:09:22.529
that we really trust. And but but
generally you probably shouldn't be able
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
00:09:30.899 --> 00:09:34.940
operating system is separate from the
bootloader. So what we want to be able to
00:09:34.940 --> 00:09:40.119
do is get from the Android OS to affecting
the, to the bootloader. And can this
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
00:09:48.139 --> 00:09:52.470
realize there were animations on the
slides, that's unfortunate. So this is
00:09:52.470 --> 00:09:59.420
sort of the normal flow chart of how these
things normally come about.
00:09:59.420 --> 00:10:03.589
You've got the bootloader, which has to
read from persistent storage in order to
00:10:03.589 --> 00:10:07.459
initialize the operating system. Like, of
course you have to read, for example,
00:10:07.459 --> 00:10:11.139
whether or not the device is unlocked, you
have to load the kernel itself. There are
00:10:11.139 --> 00:10:17.009
lots of inputs to the bootloader and
intuition is that the bootloader is, these
00:10:17.009 --> 00:10:22.550
just serve as normal inputs to a program,
which can be analyzed for vulnerabilities.
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
00:10:30.869 --> 00:10:35.880
root privileges in the operating system
you can write to this persistent storage,
00:10:35.880 --> 00:10:46.920
which means that you have that this serves
as another input to the bootloader and
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
00:10:53.180 --> 00:10:58.189
this project, to automatically verify the
safety properties of these boot loaders.
00:10:58.189 --> 00:11:04.481
That's BootStomp. Bootloaders are
complicated. There's a lot of stuff, which
00:11:04.481 --> 00:11:08.480
means you have to automate - the analysis
has to be automated in order to really
00:11:08.480 --> 00:11:11.999
sift through something as big and
complicated as a bootloader, with the care
00:11:11.999 --> 00:11:16.860
necessary to actually find bugs that are
sitting there.
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
00:11:20.310 --> 00:11:25.420
to be a binary analysis and furthermore
you can't really do a dynamic execution on
00:11:25.420 --> 00:11:29.679
something that needs to run on the highest
privilege level of a processor, so you
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
00:11:33.389 --> 00:11:37.499
needs to be a fully free-standing analysis
that doesn't assume anything other than
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
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
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
00:11:56.069 --> 00:12:02.970
specifically is the tool that we built. It
will automatically detect these inputs,
00:12:02.970 --> 00:12:09.870
that we talked about, to the bootloader
and then it will determine if these inputs
00:12:09.870 --> 00:12:14.050
can be used to compromise various security
properties of the device.
00:12:14.050 --> 00:12:20.050
One such example is if you can use this to
just achieve memory corruption for example
00:12:20.050 --> 00:12:27.649
or more abstract forms of vulnerability,
such as code flows that will result in
00:12:27.649 --> 00:12:33.319
unwanted data being written by the more
privileged bootloader somewhere. And the
00:12:33.319 --> 00:12:39.519
important thing about this analysis is
that its results are easily verifiable and
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
00:12:44.970 --> 00:12:48.579
what's happening and this is why I think
this happened and therefore I can
00:12:48.579 --> 00:12:59.290
reproduce this, possibly?" This happens
through symbolic taint analysis. This is
00:12:59.290 --> 00:13:05.550
the part that I know about, because I work
on angr, which is the symbolic execution
00:13:05.550 --> 00:13:11.209
analysis static analysis tool that
bootstomp uses in order to do its taint
00:13:11.209 --> 00:13:18.910
analysis. That taint analysis of all
execution are kind of loaded words, so
00:13:18.910 --> 00:13:24.259
this is what specifically is meant is that
when we discover these sources and sinks
00:13:24.259 --> 00:13:28.790
of behavior, through person particularly
static static analysis and some
00:13:28.790 --> 00:13:32.040
heuristics, of course. And then we
propagate these taints through symbolic
00:13:32.040 --> 00:13:35.319
execution, while maintaining tractability.
And notice wherever
00:13:35.319 --> 00:13:39.850
we meet wherever we can find pause from
taint sources to behaviors sinks that we
00:13:39.850 --> 00:13:47.420
think are vulnerable. Specifically, we
think these these behavior sinks are
00:13:47.420 --> 00:13:51.889
vulnerable behavior if you can arbitrarily
write to memory, or read from memory.
00:13:51.889 --> 00:13:55.040
Like, really arbitrary, if there's a
pointer which is controlled by user input
00:13:55.040 --> 00:13:59.980
- memory corruption stuff. And
additionally, if you can control loop
00:13:59.980 --> 00:14:04.449
iterations through your input, that
indicates the denial of service attack.
00:14:04.449 --> 00:14:11.820
And finally, the unlocking mechanism, the
bootloader unlocking mechanism, if there
00:14:11.820 --> 00:14:18.269
is if we can detect specific code paths
which indicate bypasses - those are
00:14:18.269 --> 00:14:25.910
valuable. So, yeah, so this is the
specific architecture of the tool. There
00:14:25.910 --> 00:14:31.290
are the two main modules one which is
written as an IDA analysis. You know, the
00:14:31.290 --> 00:14:35.209
big tool that everyone probably doesn't
pay enough money for. And then there's the
00:14:35.209 --> 00:14:41.829
other component written in angr which is
the symbolic change analysis. And this is
00:14:41.829 --> 00:14:51.850
probably the point where I break out of
here and actually start the live demo.
00:14:51.850 --> 00:14:58.671
That's big enough.
Okay, so we're working on a Huawei boot
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
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
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
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
00:15:27.199 --> 00:15:33.579
ninja or r2 or (???), god forbid. But,
this is a collaborative project if you saw
00:15:33.579 --> 00:15:36.970
the huge author list and people write
stuff and whatever they're comfortable
00:15:36.970 --> 00:15:41.859
with. So it's IDA in this case.
Realistically, because this is just a
00:15:41.859 --> 00:15:46.839
binary blob when you load it in IDA it
doesn't immediately know where everything
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.
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
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
00:16:12.229 --> 00:16:16.459
the sinks that we established." Obviously
you don't need a sink analysis to
00:16:16.459 --> 00:16:20.119
determine if you've got memory corruption
or not but we like knowing where the
00:16:20.119 --> 00:16:23.809
writes to persistent storage are and where
all the specifically the memcopy functions
00:16:23.809 --> 00:16:35.209
are valuable for analysis. And then, if we
run our taint analysis bootloader, taint
00:16:35.209 --> 00:16:38.759
on the - oh this configuration file is
real simple. It just says, "oh here's what
00:16:38.759 --> 00:16:42.040
we're analyzing: it's a 64-bit
architecture, don't bother analyzing thumb
00:16:42.040 --> 00:16:51.989
mode, etc cetera, simple stuff." And it'll
do this for about 20 minutes. Uh, config;
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.
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
00:17:05.779 --> 00:17:09.579
about these seeds there used the the seeds
for our taint analysis or for our
00:17:09.579 --> 00:17:17.500
persistent storage. And that I used by the
unlocking procedure. So the heuristics I
00:17:17.500 --> 00:17:21.369
was talking about - we want to identify
the reads from persistent storage through
00:17:21.369 --> 00:17:26.050
log messages, keyword keyword analysis and
long distances. So the eMMC is this is a
00:17:26.050 --> 00:17:29.689
specific memory module used by
the bootloader for secure purposes. And
00:17:29.689 --> 00:17:34.809
just it's the persistent storage device
basically. And you can identify these log
00:17:34.809 --> 00:17:39.500
messages and then we just do a diff -u
analysis back from the guard condition on
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
00:17:44.330 --> 00:17:52.149
pretty simple. It works surprisingly
often. Of course, if this isn't enough you
00:17:52.149 --> 00:17:56.320
can just manually analyze the firmware and
provide, "oh here's where we read from
00:17:56.320 --> 00:17:58.171
persistent storage, here's what you
should taint."
00:18:07.900 --> 00:18:11.600
Cool. So the taint
00:18:11.600 --> 00:18:15.200
analysis: our taints are specifically
sy-- this is specifically symbolic taint
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
00:18:19.809 --> 00:18:25.160
that has metadata attached. This is a real
symbol being used for symbolic execution.
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
00:18:29.799 --> 00:18:38.330
analysis in which you emulate the code,
but instead of having the values for some
00:18:38.330 --> 00:18:41.169
of things you can just have symbols. And
then when you perform operation on those
00:18:41.169 --> 00:18:46.450
symbols you construct an abstract syntax
tree of the behavior. And then when you
00:18:46.450 --> 00:18:52.250
run into branch conditions based on those
things you can say, "oh, well, in order to
00:18:52.250 --> 00:19:00.419
get from point A to point B this
constraint must be satisfied." And of
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
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
00:19:12.230 --> 00:19:18.960
say, "oh, if tainted data come comes into
and is is the argument to memcpy then
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
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.
00:19:28.059 --> 00:19:33.549
That's a memory corruption vulnerability
generally. Yeah, we talked about memory
00:19:33.549 --> 00:19:36.409
corruption, and we talked about loop
conditions, and we talked about writes to
00:19:36.409 --> 00:19:41.220
persistent storage with the unlocking
stuff. Cool. For taint checking
00:19:41.220 --> 00:19:46.429
specifically -- oh this is exactly what I
just said. Yeah, and part and what I was
00:19:46.429 --> 00:19:50.480
talking about with the symbolic predicates
and trace analysis means
00:19:50.480 --> 00:19:54.130
that when you see something,
you automatically have
00:19:54.130 --> 00:20:00.350
the input that will generate that
behavior. So the output is inherently
00:20:00.350 --> 00:20:06.169
traceable. Unfortunately, symbolic
execution has some issues. I was actually
00:20:06.169 --> 00:20:12.380
at CCC two years ago talking about the
exact same problem. You have this problem
00:20:12.380 --> 00:20:18.759
where, oh, you generate paths between
different between different states and
00:20:18.759 --> 00:20:24.210
there can be too many of them. It
overwhelms your analysis. So you can use
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
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
00:20:34.050 --> 00:20:37.340
have to actually analyze the function, we
can just take the instruction pointer and
00:20:37.340 --> 00:20:43.590
move it over there. And, this does cause
some unsoundness, but it's not a problem
00:20:43.590 --> 00:20:49.039
if you like make sure that the arguments
aren't tainted, for example. Or sometimes
00:20:49.039 --> 00:20:53.909
you just accept the unsoundness as part of
the tractability of the problem. Limit
00:20:53.909 --> 00:20:58.519
loop operation: that's classic technique
from static analysis. And the time out, of
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
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,
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
00:21:18.980 --> 00:21:22.880
an initialization that don't really
matter. But on the other hand you can
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
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
00:21:35.710 --> 00:21:39.919
in the device if you actually have
sufficient control over it. This is
00:21:39.919 --> 00:21:47.669
rootkit territory. You could break
anything you wanted. Then there's another
00:21:47.669 --> 00:21:52.120
component in the analysis that says, "can
we'd find bypasses to the unlocking
00:21:52.120 --> 00:21:57.860
procedure." For example, this is this is
basically one of the ones that we found:
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
00:22:03.890 --> 00:22:09.440
device to data that was written to the
device, and what this code is supposed to
00:22:09.440 --> 00:22:12.880
do -- do I have animations? yes --it's
supposed to,
00:22:12.880 --> 00:22:15.460
like, take some input
and verify that it hashes
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
00:22:20.130 --> 00:22:27.110
that constitutes the cryptographically
secure unlocking thing. However, the thing
00:22:27.110 --> 00:22:32.740
that we write to is compared to the
identical to the thing that was read from
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
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
00:22:43.990 --> 00:22:53.190
to produce the thing that will unlock the
phone. So this isn't secure. Mitigations.
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
00:22:59.440 --> 00:23:04.419
key ness is the secure encryption key that
unlocked, that decrypts the like userland
00:23:04.419 --> 00:23:13.460
data is, has embedded in it the unlock
state. So clearly, if you change the
00:23:13.460 --> 00:23:17.460
unlock state you brick the entire phone.
Well, not brick, but have to reset it have
00:23:17.460 --> 00:23:27.440
to lose all your data. That's still not
really good enough but realistically we
00:23:27.440 --> 00:23:32.950
should probably be using a more trusted
form of storage that's not just the normal
00:23:32.950 --> 00:23:36.809
normal partitions in the SD card in order
to just sort of store this state. It
00:23:36.809 --> 00:23:41.490
should probably be part of the eMMC, or
specifically the replay protected memory
00:23:41.490 --> 00:23:46.789
block which uses cryptographic mechanisms
to synchronize the, what's it called,
00:23:46.789 --> 00:23:55.269
synchronize this writes to the memory with
the authenticated process. And so that
00:23:55.269 --> 00:23:58.270
would make that would make sure that
only the bootloader could unlock it. But
00:23:58.270 --> 00:24:01.789
of course that wouldn't protect against
memory corruption vulnerabilities and
00:24:01.789 --> 00:24:04.780
there's nothing really to be said about
that other than, "hey, this is a serious
00:24:04.780 --> 00:24:11.970
problem." In conclusion, all these bugs
have been reported, most of them have been
00:24:11.970 --> 00:24:17.990
fixed. As far as I'm aware this is the
first study to really explore and
00:24:17.990 --> 00:24:22.309
develop analyses for Android boot loaders
and in it we developed an automated
00:24:22.309 --> 00:24:26.751
technique to analyze boot loaders with
tractable alerts. I found six 0days in
00:24:26.751 --> 00:24:32.409
various boot loaders and our
implementation is open source. I will be
00:24:32.409 --> 00:24:34.960
taking questions, thank you for listening.
00:24:34.960 --> 00:24:43.950
applause
00:24:43.950 --> 00:24:46.110
Herald: That was quite amazing.
00:24:49.770 --> 00:24:53.120
Okay we'll be taking some
questions from people
00:24:53.120 --> 00:24:56.890
that understood exactly
what it was all about. Yes
00:24:56.890 --> 00:24:59.110
I see somebody walking up to microphone
one.
00:24:59.110 --> 00:25:02.390
Mic 1: Thank you very much for talk--
00:25:02.390 --> 00:25:04.810
Herald: Are you talking the mic otherwise
we can't record it.
00:25:04.810 --> 00:25:06.959
Mic 1: Okay, thank you very much for that
00:25:06.959 --> 00:25:11.659
work, that was really cool. Your mystic
investigations didn't include devicing the
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
00:25:16.289 --> 00:25:21.350
analyze it and maybe it would be secure?
Or not yet?
00:25:21.350 --> 00:25:28.240
Audrey: Well, there's certainly things to
be said for having things in open source,
00:25:28.240 --> 00:25:33.360
because necessarily doing analysis on
source code is a much more, a much better
00:25:33.360 --> 00:25:41.250
defined field than the than doing analysis
on binary code. Additionally, you can
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
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
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
00:26:00.759 --> 00:26:05.820
off the still running, the analysis: the
automated results. It did not finish in
00:26:05.820 --> 00:26:12.820
time so I will run some magic, and now we
have some results. Which..
00:26:12.820 --> 00:26:19.429
applause
00:26:19.429 --> 00:26:21.859
So, here's a here's one of the analysis
00:26:21.859 --> 00:26:27.519
results. We found at this location in the
program a tainted variable, specifically
00:26:27.519 --> 00:26:33.049
the tainted at offset 261 into the tainted
buffer. This variable was used as a
00:26:33.049 --> 00:26:41.019
pointer. And that involved following the
path from along along this way. So there
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
00:26:46.320 --> 00:26:47.160
was a bit.
00:26:47.160 --> 00:26:48.619
Herald: Any more questions from the
00:26:48.619 --> 00:26:57.780
audience? There is no question from from
the internet. Okay, one question, go
00:26:57.780 --> 00:27:00.029
ahead: talk into the mic please.
00:27:00.029 --> 00:27:03.029
Question: You said that the bugs you found
00:27:03.029 --> 00:27:07.789
where responsibly disclosed and fixed.
Were they actually fixed in real existing
00:27:07.789 --> 00:27:11.860
devices or did the vendors just say, "oh,
we'll fix it in future devices."
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.
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
00:27:23.100 --> 00:27:29.780
was given. I sure hope they were really
responsibly disclosed. It's real hard to
00:27:29.780 --> 00:27:36.400
push updates to the bootloader!
00:27:36.400 --> 00:27:39.960
Herald: Okay, any more questions? okay so
00:27:39.960 --> 00:27:43.909
let's conclude this talk. People, when you
leave the hall, please take all your stuff
00:27:43.909 --> 00:27:49.554
with you. Your bottles, your cups. Don't
forget anything, have a last check. Thank
00:27:49.556 --> 00:27:55.053
you very much let's have one final hand
for Audrey Dutcher, from California!
00:27:55.053 --> 00:28:00.749
applause
00:28:00.749 --> 00:28:06.145
34c3 outro
00:28:06.145 --> 00:28:23.000
subtitles created by c3subtitles.de
in the year 2018. Join, and help us!