Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/1318 Thanks!
[Music]
okay speakers Joseph and Ilya who will
be talking about how boot loaders are
broken and how to sort of look into them
please give them a warm round of
applause what is this sound okay okay
cool yeah so welcome to boot to route
auditing boot loaders by example
Joseph Tartar oh I hack things for
ioactive and this is my second time at
Congress so I'm really excited to be
back here
hi I'm Lea this is my eighteen or
nineteen time Congress happy to be back
here too I spoke in your adding seven or
eight times before and I'm very excited
to speak here together with Joe we've
been working together on boot loaders
last year and change and this is - the
NBA coverage stuff this is some of the
things we've observed and seen so I'm
very excited to do this yes so the
expected audience for this talk would be
embedded systems engineers security
people who are interested in embedded
systems and just curious security people
just a caveat we're gonna be quickly
going through about like 70 slides or so
and a lot of its just like examples of C
source code so if you did not realize
you were signing up for an hour of that
feel free to walk out we're not gonna be
offended and in another caveat would be
this isn't really trying to to flex and
show look at all the bugs we found the
purpose of this was to kind of show
people hey if you have not looked at
boot loaders before this is our
recommended you know areas of attack
surface that are interesting this is
probably where you should get started
and in some examples of nobody's really
looking at them and they should start so
that's pretty much what's going to go on
right now so quickly here's the agenda
we'll discuss quano cool odors why
they're important some of the common
ones we looked at attack surface and
Arkan
Lucian's so there's gonna be a wide
interpretation of bootloader so
basically what we mean by that is
anything that's in your secure boot
chain and if you don't have experience
with these or you haven't looked at how
much you can kind of think of it like
from an operating system standpoint of
either land calling in to kernel space
you'll you'll have like kind of normal
world calling it to secure world and
stuff and that's kind of what you're
looking for is those pivots and when
they're processing you know attacker
user control data so why because they're
you know critical for security it's a
key component of your chain of trust and
it's very obvious that a lot of device
designers are poor hardening and
limiting attack surface and what we mean
by that is a lot of the devices we've
looked at over the last year so you'll
find devices that have like full network
stacks even though they don't need a
network stack you'll have a bunch of
code loaded up to handles file systems
that are never expected so it's just it
doesn't really make sense why they're
not limiting all that attack surface
there's also a huge under estimate of
reverse engineering people just kind of
assuming that there's no bad actors and
nobody's really going to look at this
thing and and it's this hidden black box
that that we should ignore and a little
story behind the presentation is we're
actually on a train going to a baseball
game I was trying to introduce Ilya to
the lovely game of baseball and we were
talking about u-boot and I pulled out my
phone and we went to the u-boot github
and in about I don't know 10 minutes 15
minutes we ran into like 10 bugs and we
went yeah we should probably audit some
of this stuff and a kind of inspiration
from a previous talk that Ilya is given
at Congress where he audited a bunch of
different BS DS I said why don't we look
at a bunch of different boot loaders and
so just to give credit where credit's
due
we are not the first to look at any
other stuff so this is a list of people
that kind of inspired us I've done
really interesting work and we recommend
if you're interested in any of this and
and you enjoyed it you should go you
know check these people out and see see
things that they have you know released
in papers and stuff like that so where
are they
boot loaders are pretty much in
everything you you have your
workstations phones game consoles your
TV you know everything and generally the
security basically depends on this so it
obviously really really really matters
and so with that said we basically
started looking at these common open
source boot loaders so you know you boot
coreboot grub see BIOS cafe which is
Broadcom I pick C and T encore and we're
just looking at what's on github what we
will be downloaded obviously in your
real world scenarios the devices that
you have at home or go by and start
looking at they're going to be heavily
modified they're gonna have weird custom
drivers that aren't available things
like that so you know we're not here to
argue the likelihood of some of the bugs
we found we're not gonna argue
exploitability have fun we don't we
don't know if they're exploitable we
don't move for one yeah for one we don't
really like that's not really the point
of it the point is to kind of show
people show designers what they should
be concerned with and show interesting
are researchers that might be interested
what what they should look at so you
boot is extremely common it's in a ton
of devices there's a huge very
customizable config for all different
sorts of boards and stuff there's
concerns for environment variable stuff
there's a super-powerful shell seal
sometimes he even shell injection
concerns based on environment variables
it's it's pretty funky and there's a
lots of lots of drivers sort of tons of
devices so it's kind of a great like
first up of looking at something that
kind of covers a huge breadth of the
and so features a viewboot that are
interesting would be you know networks
fact for its different protocol parsing
file systems and they also will load
their next stage images from like all
sorts of weird like archaic things that
nobody uses anymore and it's just used
by the tons of devices and in coreboot
and i apologize this is a little dry
right now eventually get to stuff but uh
but coreboot you know it's more targeted
towards a modern operating systems there
there aren't like legacy bio support it
actually they took a methodology that
other projects don't which is they're
not going to implement features that
they don't want to so if you're trying
to do Network booting or something you
use coreboot to boot into like I pick
city or something they're not going to
implement that feature these are used in
Chromebooks and obviously some of the
interesting parts are come from Google
and one main interesting areas SMM and
in grub obviously you guys are all
familiar with this the primary concern
here is multi boot spec and they support
just a ton of file system so that's
obviously the attack surface you'd be
concerned with but the interesting part
here is that there are you find versions
of grub so that's kind of like your
secure boot break right there if you
find a vulnerability that's an assigned
version you can now load that into your
UV and and exploit that vulnerability
and and you're good to go and then see
BIOS is the default BIOS for ki mu k vm
this supports legacy BIOS stuff so
you'll see that this gets booted into
from things like core boot this supports
a TPM communication so that's kind of
interesting and it's the compatibility
support module for you fee and ovm F and
then Broadcom cafe so this is used in a
ton of different like network devices
and TVs and stuff like that and the
obvious attack surface there would be
network protocols the network stack
that's what you'd want to look at I pick
C this would be more more network based
stuff
various parsing and similar to grub
there's you feasts on versions so it's a
great potential pivot for secure boot
stuff and then finally tiyanak or
there's a really no introduction needed
here there's been a ton of great
presentations over the last like 15
years people just you know doing doing
everything to this thing and due to that
since it's pretty much the most
scrutinized one out there it's it's
really mature compared to everything
else so when you bash tiyanak or realize
that it's way better than everything
else so and there's a lot of like
implementations built on top of it like
platform specific stuff Qualcomm's a abl
on xbl things like that so you'll have
all these you have the base based key on
a quarry dk2 and then you'll have all
the custom stuff built on top and then
related to boot loaders you have things
like trust zone and that's kind of where
I mentioned you have like normal world
and secure world you'll have these
interesting pieces of code that are
running into those those secure areas
that you're going to want to look for
you know pivots into there so you can
get access to two secrets and then and
obviously from the host operating system
the the attack surface there would be
you can modify things like NVRAM so you
can set variables that when the next
time you reboot the bootloader is going
to processes variables so and this
slides more for reference later you can
get the slides or take a picture or
something these are just links to some
instructions for building and and
whatnot so if you wanted to start
looking at these you can quickly build a
little environment and poke around so
just really quickly to go through you
know the concept of secure boot you kind
of have your your chain of trust you'll
have the boot rom that will then verify
and load various other starters loaders
that then verify and load the next thing
and you'll sometimes have a TPM
involvement you'll have some trust on
involvement and then OS interaction
stuff like the OS basically setting
things like NVRAM which will set you
know boot
you know configuration stuff well not so
the boot ROM itself is something you
probably seem to talk about courtier OOP
I think earlier it was it's really
important because it can't be patched
it's a hardware revision would be
required if vulnerability is found and
and it's so early in in the stage and
you would basically compromise
everything after it that is where you'd
want to go it's extremely bare minimum
it does some initialization of hardware
and memory stuff and you'll find things
like maybe implementations of fastboot
so you have a USB stack so that's a
obvious attack surface you'd be
interested in and then it will you know
verify the signature of the next stage
and then boot that and then you move on
to the to the next stages and that's
where they start initializing the the
rest of what's necessary and network
stacks SMM handlers and whatnot and
they'll basically just keep and keep
handing off and then you'll run into
things like trusted boot in measure boot
which is you know a verification and
then measuring which is kind of more for
for logging and and whatnot doesn't
actually mitigate anything it just kind
of alerts you of stuff so some some
hardware environments are a little
different like the secure world stuff
you'll have our mattress own windows as
VT l 0 VT l 1 hypervisor stuff and then
yeah i'm basically repeating myself and
then eventually the the operating system
that's going to get the kernels can be
loaded it's going to be verified and
then eventually start running and and
then you can have fun so early
observations is everything we've pretty
much looked at that's open source
there's no privilege separation so if
you were to compromise a piece of
component you pretty much rule
everything and what's interesting is
there are some proprietary boot loaders
that you're starting to see like Apple
for example they're doing some some
aspect of privilege separation so if you
or to to exploit a portion you didn't
necessarily control the world and so
right now at least all the stuff we
looked at did not have anything like
that but maybe in the future we'll see
that so this is the list of the attack
surface that we think people should be
interested in and focusing on you have
nvram file systems and files all network
stack protocol stuff all various buses
you know SMM DMA and hardware stuff the
the interesting thing about buses that
we've noticed is that embedded designers
seem to inherently trust anything that
an end user should never interact with
so they go ok and I'm user uses USB so
we should verify some of that but they
do a bad job but an end user doesn't
play with the spy flash so just
inherently trust or an end user isn't to
the TPM so just if the TPM says
something run with it and they mess it
up a lot so nvram these are the various
environment environment variables that
can be configured you know for the next
boot cycle and like I said it's
basically processing of user controlled
data so if you start looking at some of
these boot loaders here's the
interesting functions you'd want to look
at for example any boot you just kind of
call for environment get and grep
through and you see them grabbing the
environment variable and see what they
do with it if they're not doing a sort
of validation you're gonna hit a bug and
so an example of that would be right
here you see there's an environment get
for boot PVC I it checks if it existed
it will then do a stir length and then
just mem copy it directly into a buffer
without validating that it can fit the
buffer and this is actually kind of
funny earlier today we were like yeah we
should try to exploit one of these just
to show it so we we toured with this one
and you know just threw a bunch of bytes
and it starts just kind of sending these
weird packets over the wire and
a bunch of a bunch of bootp stuff you'll
see later on you just have full raw
packets of of whatever payload we send
but it wasn't very realistic it kind of
went started getting into like the key
mu like network implementation stuff so
we so we kind of avoid it and moved on
to a different bug but as you can see
it's very very easy for you to start
looking at the stuff and being
interested in it and and quickly set up
an environment and and mess with
exploitation and and we'll get into it
but there's no mitigations so as you see
there's a bit of a pattern here
environment get hostname mem copy with
sir length no no checks it's 120 by
buffer environment it would be tough
stir coffee mmm really you know it just
keeps happening this is kind of what
we're talking about just the quality
code is is not not very great this is
was funny is when we were messing with
that boot PVC eye stuff earlier this
morning we went oh that's gonna be more
involved so it was like well let me just
go find a different bug you know Tim I
said oh yeah I found a different stack
smash okay let's let's work on that one
it's just like this is a perfect example
they in fire may get the the variable
then they'll grab the very first element
of that variable as a length and then to
use that as of length and yep and it
keeps happening so just a quick example
see this
so the the attacks in area of this would
be you have a device you have NVRAM that
you can physically modify the
geophysical access and this is kind of
an example of the default NVRAM so we
just threw you know and if i my variable
with 600 bytes and you'll see towards
the bottom there's 4 bytes where we
threw a function in there and that's
that's the address so just this had to
do with the g FF s 2 file system loading
so you didn't you just do FS load and
it's one such hood being executed so
this is
[Applause]
sorry I can't see so obviously if you've
never looked at this stuff it's kind of
fun to to play around with them you
should you should start poking at it
because uh why not and screen shot sweet
cool cool so that was a the NVRAM attack
surface which is usually the most fun to
play with programming the spy flash
sometimes may take a little bit link but
in terms of attack surface and fun
things to play with it's it's you know
as joe said often overlooked and so it's
easy to 2008 and so you saw all this
esperan thefts and mem copies and string
copies so there's a lot of fun there but
obviously there's not just NVRAM there
was more attack surface to sort of a
trusted put environment and obviously
one of them is a file system right
because this thing needs to boot and it
needs to find images in the short
somewhere in your file system sort of
brings order to that chaos and so
basically you need to malloc your file
system and often file systems are not
signed or are Tegrity checked or not all
of it is because before you can do that
you need to be able to read something
right and so obviously an example of a
comma file system would be fat file
system if you know if your boot
environment supports loading your USB
Drive and for storage it's probably
going to be fat depending on and in the
flash itself may have its own
proprietary format or it may use x2 or
you know something else but clearly the
file system parsers I mean that's prime
attack surface closely related is
obviously the files inside of your file
system right now depending on what your
boot environment looks like some of
these files are going to be integrity
checked but some of them might not be
right and so those file parsers are
interesting attack surface and if you're
either looking for bugs or you're
building a products we would highly
recommend fuzzing these and it's like
starting with a FL is probably a good
starting point but we'll show some
examples of some bugs we saw in certain
in a number of boot loaders
so we'll cover x2 we'll cover a bitmap
splash parsing one I think the animals
are sort of examples of where there
could be bugs but those two will cover
so this is this is grub and this is grub
mix two and grab x2 you know this is the
sibling coat so it looks to file system
and it goes oh okay this is a symlink
how do i parse the symlink and so the
symlink says hi I'm sealing I'm a
symlink I'm this big and what grub does
it so great I'll add I'll allocate that
much size but I'll do one more for no
bites and of course that is a classic
integer overflow and the grub memory
allocator actually returns a valid
pointer for a zero size so this a
perfect primitive so you get a pointer
to something that is zero size and then
it actually reads the assembling content
from the filesystem into a zero size
buffer and obviously that's going to
cause memory corruption and a primitive
you can't see it here but a primitive is
really nice because that particular read
function actually if if there's if it's
if there's no much much more on disk it
stops reading so it so even though you
can save read for gigs you can make the
layout so it only reads let's say a
thousand bytes or a hundred bytes and so
you have this near-perfect primitive to
cause memory corruption this is this
wasn't IANA core for example this was
the bitmap splash screen parser and I
don't know you know the bending about
bitmap internals it's a very simple
format but basically you can have a
4-bit bitmap and that gives you a
palette of 4 by 4 which is 16 bytes and
so the idea is if you have a 4-bit
bitmap then it has a 16 byte palette and
so it goes and reads a 16 by palette
except you you till it you tell it how
big the palette is and you can say okay
I know you're expecting a 16 byte
palette but I'm giving you a 206 by
palette and it'll read it into a 16 byte
buffer so that was broken and then for
the 8-bit bitmaps similarly it was
broken the same way and these are just a
tip of the iceberg there are many many
many more just does not this did not
take long to find but let's let's let's
move on
obviously okay now that we've looked at
some local stuff it's a physical stuff
what what about what about remote you
know how do we what is there right
obviously if you're talking remote in
you know if the modern world you're
talking tcp/ip right so you need a
tcp/ip stack and you need to have some
services that you either expose or that
you have client codes for that you go
talk to you right and that's bootp and
dhcp and dns and you know i scusi and
NFS and if you're in a corporate if
you're a court net you probably want to
have IPSec and then HTTP and HPS and
TFTP right and sure enough you know most
boot loaders have code for this and then
you start asking you okay well what's
what's the attack surface you know for
tcp/ip if you implement your own stack
well hey good luck because you're gonna
screw it up but secondly it's like okay
well if you look at these things you
take a step back and say okay well
really this is all mostly TLV parsing
and so you go look into like what it is
sort of the the things I can go wrong if
you do deal people to be parsing and you
know they'll be on out of bound reads
pretty much everywhere and you'll see in
those loops and lots of places and
things like that if you look at the
protocol top of that like DHCP and DNS
you know you can you have sort of your
standard sort of network attacks where
you'll see likely stealing or cache
poisoning or things like that if you
don't protect your ID so if you have a
static ID you don't validate your IDs or
you generate predictable ideas you know
you can have you can have these kind of
poisoning stealing man-in-the-middle
attacks right and then thirdly obviously
you know the thing we really like to see
is memory corruption box you know you do
in a day you you take Network data and
you parse it and if you do it wrong you
may cause memory corruption bugs another
some sometimes overlooked interesting
bug I think in a when you network
forcing is when you have information
leaks so there's this often manifests
itself
I mean heartbleed of course was one
example it was it was a perfect
primitive but generally it'll be
distinguished
some kind of packet as a response to
something and you know you you'll have
done the memory allocations but for some
reason not neutralize something and so
you end up sending undersized data over
a network
so this is sort of the common things you
see Network sacks in general okay so if
you are looking for these kind of bugs
in a food environment or if you are
building a product that does this I
would highly recommend fuzzing him
there are numerous interesting Network
fuzzers if you're looking for Network
sacrificing I would recommend is sick
that's pretty old but it's still
incredibly incredibly effective it tends
to tends to break most network stacks so
with that said let's show some examples
I was so you boot for example this is
the u-boot dns code and if you see that
that's the t ID that's the dns ID and
it's basically they give it a they use
the static dns ID of one for all dns
packets that they send out so doing dns
man in the middle a you boot environment
is extremely trivial you you guess that
the the dns ID by saying that it's one
and you are correct 100% of the time
so this is brought coms coffee and this
is the the the HP parser and it
basically has this sort of this junk
stack buffer where it just needs to read
something out of a buffer and it goes
and says okay well get me the length of
that thing and it's a un date so that
means it can represent 0 up till 255 and
then it reads 0 up until 255 into that
junk buffer so that's a stack corruption
right there if you didn't look at the
coffee at ESP parser it's very similar
where in this case it has a 5 and 12
byte buffer and then it basically copies
the entire rx buffer into it and this is
internet so up to up to 1,500 bytes gets
copied into this 5 and 12 byte buffer
again causing memory corruption
obviously we're not done with coffee yet
because it has such a beautiful code so
this is the the coffee ICF beeping
handler and this has this really cute
sort of use after free bug or
double/double freeware it basically it
sends out a ping and then it sits there
receiving that you see the while loop
there and it basically sits there
receiving packets until it finds the
right one but it also because it doesn't
have an absolute
it has a timeout and there's this
interesting condition where if the last
thing it looked was the back of your
look before but it also timed out at the
exact same time it fries that packet
twice which obviously can lead to memory
corruption again we're not done with
coffee yet oh right there we go now that
with coffee yet so this is the this is
the IP handler in coffee and if anybody
has ever looked at an IP header which I
would assume most you have you'll know
it has a header linked and the total
length and of course coffee needs to
know this because it needs to know where
stuff is
but coffee validates neither the IP
header lines or the total length so once
you start messing with those coffee
blows up really fast so that was sort of
a quick overview of all the trivial TSP
and TSP related bugs that show up in
your after bootloader so but let's say
let's say you got that covered and let's
say you know okay what's what's the next
thing what what what more sort of
network stuff can we do and then of
course what comes to mind is Wi-Fi you
know 811 and I a surprising number of
boot loaders don't have a turtle on
eleven so I don't know if that's sort of
a sort of purpose or it's just sort of D
we didn't we didn't get to having this
feature yet but we will at some point
and obviously it'll have bugs when we
implement it but we did find one that
has it and I'll get that in a second one
thing I did want to mention is that if
you look at a tor 2.11 like frame
parsing depending on which device you
have in particularly which radio your
device is using it that you'll have
radios that do a lot of parsing on the
radio in which case the stack is kind of
covered because it's at least you hope
it is where the radio does a bunch of
validation but then there's a whole
bunch radios that sort of you know they
take package from the wire and they just
don't do anything and just pass it on to
us
that's the stuff that's interesting from
from a tax service point of view if
you're looking to attack the bootloader
and not deed firmware so yeah we looked
at pixie at pixie and of course you know
anytime you do any kind of a Wi-Fi stop
the first thing you do is you you're
looking for an SSID right this is what
this thing does and
you know it sort of has this SAT buffer
which necessarily can be up to 32 bytes
so that is 32 well sorry 3 bytes concert
to 32 plus 1 and it has this loop where
sort of goes over ie stead it gets and
then when it finds the right as the ie
for an SSID it says okay we'll take this
ie and I will do I you length and I in
life is you and 8 so it can be up to 255
and it copies the SSID ie into the SSID
buffer which is only 32 bytes causing
memory corruption so that's I pick C for
you okay so the next one if you're
thinking networking would be Bluetooth
and Joe and I have actually we've looked
at proprietary boot loaders that have
Bluetooth Bluetooth support
unfortunately we can't talk about those
books because they're covered by down
into closed agreements and we tried
really really hard to find a similar
equivalent in any kind of open source
bootloader and we couldn't find one so
unfortunately we can't give examples of
sort of bluetooth bugs in open source
boot loaders but I do kind of wanna in
general terms talk about what we have
seen and where we suspect the bugs are
going to be if somebody does do this in
an open source bootloader or so so many
men it's a new bootloader so and also
like if you're gonna do Bluetooth in a
bootloader it's usually for you know hid
device right this is for keyboard mouse
this usually ends up being for consumer
devices but in general if you look at a
Bluetooth stack and you're looking for
any kind of you know parsing bugs
there's three sort of recurring teams
that we saw when we looked at the
Bluetooth stacks that we have and this
is if you look at the lower layers like
l-ltp cap and things like that and this
is usually related to sort of frames and
frame lengths so very very large frame
so a frame can be up to about 65,000
bytes because it linked is a human 16
and so if you create really large
strains like right up to the edge that
tends to blow up bluetooth stacks you
don't want is if you create very very
very short frames you know less than
what something is expecting that tends
to blow blow up your Bluetooth stack and
then lastly because ll to cap can have
fragmentation so you
have individual fragments that you all
add together and every fragment can be
accidental bytes but the whole thing can
be up to 65,000 bytes a byte
65,000 number of bytes so if you start
playing around with the fragmentation
we've numerous BlueStacks have blown up
again I wish I could have shown an
actual bug here but I wasn't able to
find any in the open source output
loaders so moving on to USB this is this
is a prime attack surface in boot
loaders obviously if you haven't
followed the news in the last couple of
weeks and months this has shown up in a
number of devices this is at least up
until recently I think was sort of under
underreported or sort of people didn't
quite care about it but to meet you guys
we stack is like to that's the if I Nick
anytime I look at USB load at a boot
loader
my first thought is you know NVRAM and
number two is USB right and USB is
interesting because obviously a lot of
bootloader support USB because they'll
use it either for storage or you know
things like Ethernet dongles but often
for storage or you know either you
exposure to files or you try to do some
kind of recovery boot from USB or
something like that
right and so basically if you start
looking at how USB works at a slightly
lower level it it's not quite like it's
not like piece like PCI it's more packet
based and so what happens the date when
when a device talks to a host the device
is asked for quote unquote descriptors
and these descriptors say certain things
about your device and based upon the
number of descriptors that the host ask
from you and all the answers you give
them in descriptor responses the host
ten can then figure out like what kind
of device you are and like what class
you are and what functionality exposed
all these kind of things and so a lot of
these descriptors end up you know being
parsed and being parsed wrong and so
generally we often see either
straight-up overflows or double fetches
because the way descriptors were
is there variable-length content but the
headers are predefined in the way it
works is you first asked for the header
and then based on the length and header
you asked for the thing again except the
USB protocol doesn't allow you to just
get to the payload you have to reread
the whole thing so you have to reread
the header that you already had and so
in most implementation what happens is
you go get the header you allocate a
buffer and then you go get the header
and payload again and you overwrite the
original header what meat which means is
you get to overwrite the original header
length and so you can have a talk Tao
where your device gives you a header
with a good length and then the second
time it gives you the scripture with a
bad length and if your host doesn't
validate that boat lengths are the same
bad things happen and yesterday a
straight-up overflows happened to
because nobody ever expects the USB
device as an example in grub for example
where it goes and gets a descriptor and
the descriptor says oh here's my confit
count I have this number of
configurations go and fetch those in the
script as well and there is a predefined
array of number of configurations that
grub has and it doesn't correlate that
with the conflict count it just always
assumes the config count is less to or
equal to the array and so if you have a
malicious device and you say hey I know
you're a sir two bites toward two
elements but I'm gonna give you 64
configurations it'll happily write 64
configurations in a place I can only
hold 32 of them and exactly the same
thing for a number of interfaces tiyanak
or had similar bugs where this was
tiyanak or where they go and get a
descriptor and then the scripture length
says okay now go fetch me the whole
thing and use that descriptor length
except the the original hop descriptor
was a very small struct and the
descriptor linked is a human date so he
can send up to 255 bytes and so that
would have smashed memory and caused a
stack corruption and so as you can see
here the the fix here wasn't actually at
a bound check but just to make the
buffer bigger because you know the
length is you in eight
so if you just make the buffer 256 then
any like you and you're like you give it
will will fit within the buffer yeah
this is an example in a sea bios where
this is the classic double fetch where
it goes and gets the header doesn't Alec
base on the header and then it gets the
header again with the content and it
doesn't verify that config W total
length is the same thing as C F G W
total length and because that
verification isn't there whoever calls
this thing can no longer trust W total
length because it could be invalid and
so as I said USB to me is one of the
prime tax services to secure boot and so
I want to sort of very very briefly
mention two recent real world cases
where devices got broken into because of
you as we parsing in a bootloader so
this was this is a case of the Nintendo
switch d-dad Tegra this was done by the
field overflow people about a year or so
ago that basically you know you give it
a link that's not validated and then a
mem copy and that causes memory
corruption and then the recent iPhone
checkmate this is slightly more
complicated because it wasn't a straight
up memory corruption but it was you know
if you fiddle around enough with state
it sort of gets out of sync and it has
all these pointers that is still
considered to be alive but the memory
has been freed and so you ended this
ends up what I use after free but it is
because of a sequence of USB packets
that are being sent alright so that's it
for USB obviously a bunch of the buses
or almost any bus on your device if if
your boot chain uses it is interesting
attack surface and this is spy I mean
spy flash shouldn't be trusted SDIO i2c
LPC even even your TPM right if your TPM
responds you get back from TPM can't be
trusted because somebody could dissolve
your TPM and pretend to be your TPM and
if you don't now validate the data you
get from TPM you end up with memory
corruption so this is for example what
happened in see BIOS see BIOS has this
talks to the TPM and it goes and gets
this structure and you can send it less
than what it expects
and then basically they they subtract
some size of a struct - less what they
expect and so that causes integer
underflow which ends up with a really
big size and then that size is given to
malloc and malloc internally has intend
overflow so that really big size then
becomes a very small size and then they
copy into a net cause memory corruption
and so this is a combination of two bugs
right ones word decisis are wrong and
then secondly is where the Matlock has
an internal integer overflow and this is
the this is the malloc internals of C
BIOS which I don't want to dive into now
because it's pretty convoluted and
complex I'll leave this as an exercise
to the audience to figure out where the
into overflow is and technically it's
not in overflow because it's a bunch of
shifting being done but it essentially
comes down to an int overflow yeah there
we go
yep okay so those are service attack
service that is interesting but often
overlooked on devices except for you fee
is system answered mode and I mean there
have been over the last decade and a
half numerous numerous presentations
about estimate attack surface and and
breaking SMM handlers for you fee
because it's an x86 thing and you see
this in goofy stacks and it was a sort
of cat-and-mouse game where for years
you know somebody breaks something and
then you he fixes it and then somebody
breaks it again and you fix it again and
somebody makes it again usually goes
okay let's move mitigation for this and
has gone on for like 15 16 years and
occasionally people still find bugs but
by and large you fee does fairly well
now regards to us mmm handling there's
some third-party stuff that still breaks
occasionally but in general they got a
handle on this now what if you using x86
but you re implement your own boot
loader and you don't use you fee right
well that means you're gonna run into
all the same problems you fee had and
you're gonna screw it up in all the same
ways and it'll take you another 15 years
to get it right but I guess I guess if
you were to try on the first time this
is what core
coreboot does and to their credit they
say oh we get input we should range
jacket and their range deck says to do
[Music]
[Applause]
okay
so now I talked about a bunch of busses
the the thing to me that sort of
separates that from from other things is
when you do DMA generally for as long as
DMA has been around the ideas been dmas
came over right if you get DMA then you
know that's that there's no trust
boundary obviously that's so longer true
right we have IMM use and if you use
them and then if you have a device it
has this available then old Sun DMA can
be stopped it can be contained it can be
regulated and so it's no longer a sort
of game over and you can implement a
trust boundary few things there a if you
are an embedded device and you're using
on you you are way ahead of the curve
because very not not that many people
are doing this right you should but it
takes some effort there's obviously many
different I am use depends on your
architecture and sort of the board you
have in all sorts of things so Intel
sweetie de Armas at smmu AMD has like
the device exclusion in it it's got a
few other ones as well but basically if
you use one of these you can sort of DMA
is no longer the game of now that mean
that doesn't mean that you know you're
in the clear once you define the amazing
the tax service you have to defend it
and and that's where you get some
difficulty because you'll end up using
drivers that have been written before it
was a trust boundary and I mean no one
has ever written a DMA handler and with
trusts way to trust boundary of mind
because because he was stupid there's no
transparency so now well son if you
start using the IMU you have to go back
and all your drivers and look at okay
where am i doing DMA and now I can no
longer trust what what's in when I get
back from DMA and you gotta go validate
all this stuff but even if you do all of
that right which by the way is very hard
and you probably won't do it right
but let's say you do secondly because
DNA is now a trust boundary anytime you
open up a memory window for a device you
can't just open it up you have to clear
the memory first because otherwise now
you're leaking memory to a device right
so all these sort of new things sort of
show up if you take TMA's to trust
boundary and let's say you do that right
well now you still have a dependency on
the iommu because you are assuming the
i/o news perfect when it probably isn't
right I haven't I haven't really gotten
to this part yet but I one of my plans
for the future is to go look at IU muse
and see if I can you know attack I
reviews and then find bugs there I
strongly suspect there will be side
channels and logic bugs and maybe maybe
even some inflammation bugs
so bug wise this is where sort of gets
designing right so this is this is this
is what this is you feet today indicate
you platform code where it has support
for MU and they're ahead of the curve
but if you look at the spec
there's no good handover protocol from
from you feet to the next stage and so
you fee basically boots up and very
early configures the eye room you and
make sure that devices can't you can't
peek or poke arbitrary physical memory
and then it get does all of its stages
and then it's about to hand off and it
goes well I don't know if the next guy
supports item mu so it undoes all the
IME program it does turns the thing off
opens up everything and enhance it over
to the next guy so all the you did all
this work for nothing and this is this
is a spec bug and it's being worked on
people Intel very much aware of this
people Apple the fix this for their
devices this is going to get fixed in
the future but given that this is done
has to be done by spec you know it takes
a while because he I give to get people
to agree to it and then him have
numerous different implications
implement this and this is where I hand
back over to Jo yeah so hardware it's
pretty much out of scope for the
presentation we did not look at any of
this but we thought it would be naive to
not at least mention it to people and
will mean will we mean
that are like glitching side-channel
also look and stuff and so with
glitching you have like fault injections
and a lot of times people go after
things like the signature verification
stuff so they'll basically glitch that
part and then they'll start running on
signed code and a recent example of some
glitching was done by fel overflow for
the ps4 siscon and I forget the
specifics it's been a while really
really good blog post you should check
out but I think it went to like an
infinite loop like oh go to debug mode
or something and it would say that's not
enabled infinite loop and then it was
glitch out of it and then it's
initializes debug run and so stuff like
that obviously should be concerned with
then then clearly side-channel with
timing discrepancies power discrepancies
things like spectra meltdown a
speculative execution in general these
are where people are leaking secrets
very going after keys so they can start
signing their own code stuff like that
and then chips suck and this is somewhat
interesting because it's obviously only
relevant for a very sophisticated
attacker it's going to be somebody who
has very expensive equipment they do
things like be happy and they use fibs
and Sam's they can do things like
optical ROM extraction and get the boot
ROM and then star out of doing that and
then and then you know find a book and
exploit it
and obviously totally out of scope for
the presentation but one thing that's
interesting about this is kind of kind
of presently it's it's still you know
not a lot of people have this expensive
equipment but I think very soon you have
people like John McMaster and stuff who
who have like SM in their garage right
and so you're gonna eventually start
getting these regular hackers in their
garage that will eventually get this
equipment as the older equipment becomes
more affordable and and maybe that opens
us up to to more realistic instead of
people just kind of ignoring it and they
go yeah I'm not worried about somebody
with you know a quarter of a million
dollars worth of equipment now it's
turning into somebody who dropped 10k or
50
okay and then you know quick note on
code integrity um it's it's something
that people mess up a lot it's kind of
hard to do right you have people that do
a week or crypto you have blacklist
problems and an example that is you know
there's finite space for their blacklist
it'll eventually get exhausted so when
you have stuff like where I mentioned
you have assigned grub there's a known
bug and an assigned grub of an area that
was released by Kaspersky and if if
that's not on the blacklist of your
euphy platform at home you can just load
that up and then exploit it and you just
broke secure boot like and it's not
going to get fixed until that platform
hasn't up today blacklist and eventually
if all this crap gets blacklisted
eventually that list will be full and
then they can't block a list anymore all
right so it's it's a there's a concern
there and then you'll have issues where
they they'll only sign like certain
portions not not the full blob so you
can you know still modify certain parts
or sometimes you'll see they'll just
check for a signature existing but they
don't validate it you know I really
really dumb dumb stuff um so conclusions
obviously this is the tip of the iceberg
there's a lot of stuff we didn't look at
and if it wasn't clear we did not really
audit these things we we literally would
like chat with each other every day and
be like hey we need a/c bows bug okay
give me an hour okay I got one okay
check the box and then let's move on to
the next one we our goal was to have a
an example of a bug for each list of the
attack surface an example of a bug for
each list of the thing we looked at and
that was it so you know once we found
one we stopped so you guys should you
know go hunting and have fun but if it
wasn't obvious there's a surprising
amount of low-quality code it's it's
kind of crazy and it's pretty clear that
not a lot of people are looking at this
stuff and one thing that kind of sucks
is you get to NDA hell really really
really quick if you want to look at it
any of this proprietary stuff so if
you're interested in Qualcomm stuff for
example and you want to get some
documentation or look at it you pretty
much have to sacrifice or firstborn to
get access to that stuff like it's just
not gonna happen and it's a it's kind of
silly so you know kind of like our
advice and call to action is um you know
people should be minimizing their their
image their food environments their host
host environments
you know turnoff features you don't need
if you don't need a network stack why
have it if you don't need USB why have
it all you're doing is enabling a TAC
surface for somebody to to leverage and
something that we see a lot which is
insane is like these little embedded
devices that are running Linux and they
have literally more drivers than our
desktop at home and it's just like what
is going on here does it doesn't make
sense you should really really really
work on limiting the attack surface and
really quick mitigations there aren't
any in most environments yeah yeah there
just aren't any as you see from the
example from before that was you know
just from this morning just really quick
you know smash and you know over it the
stored PC and and that's it like there's
no ASLR there's no no anything like that
code for integrity whatnot but there's a
link to a github and that is an intel
employee that have this has gone and
implemented a lot of these mitigations
that are moving into Tiano core so they
are way way way ahead of the game of
everyone else because they're actually
getting a lot of these mitigations which
is quite impressive and you should you
should check it out because it's
interesting code so kind of a call to
action we really hope that this was
inspirational to to a few of you if
you've never looked at this stuff and it
was always this black box that you
weren't weren't weren't sure about you
should just start poking around go go
find the slide where we showed where the
the you know build instructions were and
go build some of these things and mess
around and and you're gonna have fun and
like we said with no mitigations you can
work on some some easier exploit to have
stuff and
it's cool right but it's clear that a
lot of people need to be reviewing this
because it's clearly not happening
people should start fuzzing interfaces
everything we kind of showed should have
been found with with basic fuzzing we're
kind of at a point where we're too said
I'm just going to take like a teensy or
something and and have it just you know
and do that
classic descriptor double fetch because
I think we've seen that in like every
USB stick like it's just like just make
a device and just start plugging it into
stuff and just watch it break and then
obviously periodic reviews and whatnot
but yeah that's that's pretty much it
yeah
[Applause]
well thank you now we have about 10
minutes for Q&A and we will start
immediately with the internet I think
you has the grub issue being fixed yet
and was the code unique to grub or
borrowed from you know as well I don't
think it's been fixed yet and this was
the this was from whatever the official
grub repository was all right if you
have a question in the room please line
up at the microphone so I can see you
and now microphone number two always so
let's say you want to make a more secure
laptop so you can see we take coreboot
take a static card so that everything is
in compiled in no number no modules but
what about the text attack surfaces that
say somebody tries to interrupt a line
of white it is booting for example that
you may be some somehow getting to make
a maybe DMA excess because you you
somehow interfere with a let's say
Broadcom network device that has some
special firmware to optimize the traffic
or something and then that this thing
gets buffer over floated above offload
and make some problems on the on the bus
or something are you talking about
attack surface from devices yes yes I
tell you you want to make a good system
so I think the best you can do if you
have a laptop that you take coreboot and
you take a Linux that you completely
compiled without module support
everything you want to have is in the
static kernel and then just boots and
the credits in the coreboot and so in
the flesh but you can get problems by by
by let's say some devices that just spit
into your memory because they can do it
in a master yeah that's that's that's
definitely concern and that's one of
things we were like okay well if if if
you do use DMA as it has been forever
than that then it's game over
luckily nowadays we have IOM use so you
depending if which situation you are in
and what part where you have you can
configure your device to use the iommu
and if you're doing that then even if a
certain hardware device is compromised
you can still try to protect you know
your CPU and your hosts from the device
by having the iommu then I think I hope
it ask you a question but it's about as
good an answer that I can come up with
so that's a bit so this is the maximum
you can do against some attacks I mean
from from a device and so I want to make
an extreme hard laptop that you use in
extreme hostile environments so again
you want to make it hard at laptop
that's you use in the holster the vial
right I mean I think that's the best you
can do right I mean you can go and look
at your host West and look at how it
parses the stuff that comes from the bus
because there'll be Dobby bugs there too
but I think that's the best thing come
up with yeah I mean you minimized the
attack surface as much as you can right
and then once once you have as minimize
as possible then you just kind of hope
hope there's nothing there if you don't
then you'd only to code-signing because
you have everything in your flesh or
you'll still need some stuff oh you mean
stop the rows on the host yeah I mean
let's say you have to code on the Linux
kernel in in the flesh and so everything
is that we have that time and you maybe
take this discussion okay after the talk
because we have more questions thank you
Thanks signal angel please what is your
favorite disassembler and that you use
by reverse engineering the bootloaders
we didn't really we just looked at our
source code I mean for this particularly
in this particular case most of it was
white box so we didn't have much except
for the exploit we didn't have much need
for for a disassembly I guess a little
bit of gdb in general when we do do
reverse engineering I mean guys I just
might go to I've been playing around we
could go a little bit it looks promising
has on do which is nice but those are
usually and then you know for doing
Luke's type stuff gdb is nice when
you're doing debugging but generally Ida
microphone number one place I have two
questions
what's your opinion on the arm trusted
from architecture I'm
I have to work with this and I'm a
little bit shocked it's a little bit
over complicated and the second question
is should we kneel also question the
boot roms because what I've seen is a
special project it leads me to believe
that the boot ROM is also very broken
and then it's the question if it's
really necessary to harden the other
stuff and right yep yeah those are those
are really good questions by the way it
sounds like you're working on this so
well your first question was what again
what do you think about the arm yes I
like you I've touched upon it in a few
engagements
unfortunately anybody can creat stuff I
can't really talk about because it was
covered by nonsan yeah I see aware this
is this problem but I'd share your
opinion that there are some things in
there that are troubling what regards to
to boot roms you're spot-on sir I mean
this we tried to bring this up into one
of the slides is if there's a buck there
you can't fix the hardware revision is
doing way to fix it so you kind of
screwed there are some designs you can
do to try to minimize it so you could
say okay well you couldn't in your boot
room in your boot rom you could have a
feature that allows for a quote unquote
patching to boot rom where you can have
a piece of something on storage that
could overwrite with the boot rom
supposed to do obviously up until that
point whatever's in the boot problem
still you can't fix that but you can you
can minimize the amount of stuff in a
boot ROM that's not patchable but you
can't minimize all of it I mean there's
gotta be some of it that is locked
burned in hardware and can never be
fixed for that device I'd love to hear
of a better solution I don't know of any
no I was just gonna say this kind of
touches on when we said people under
estimating reverse engineering they kind
of just keep it super super black box
and it's the secret thing and then you
know when somebody finds a way to to
dump a boot ROM they start looking at it
then they just see you know a bug and a
USB key just be stackin and this which
goes down and her iPhone or whatever
else right so see that's from my
perspective it
I would say it would make more sense to
do more open open auditing a lot more
eyes see it instead of hiding it in the
corner and and pretending like well
that's okay because nobody's looking
that's that's at least my perspective on
it I know why why people are super
secretive about it but you need more
eyeballs maybe if you've got the right
context as my wish would be to get blank
chips so I could flash them with my own
boot ROM so I have a method to improve
things and and keep the attack surface
minimum
yeah and then there's gonna be two other
armed eyes on there that are
circumventing everything that you just
did do we have more Internet questions
yes
are you aware of any good and maybe even
free bootloader fuzz oh not in this hole
I did I mentioned a few places so if
you're doing any kind of file based
stuff and you can isolate it AFL is you
know that's to go to these days for
network stuff there's a couple of
interesting ones like it's sick and
there's some Wi-Fi buzzers and and I
think there's you know some you know
sponsors or things like that so that
works I would say the best way and my
opinion would be to pull out the
interesting components that are doing
the parsing and the stuff you're
concerned about and write a harness for
that so you don't really need to to try
to write a fuzzer for that environment
you just pull that feature out and
harness it up and then let it you know
run on a bunch of cores yes I think live
buzzer might be very helpful there all
right number two please I help reducing
the occurrence of such errors by using
another programming language like um
that would feature more secure things at
compile time or during run time like
maybe rest will it happen if yes are
there alternative projects that use
other languages other than C so III
think you're right I think we can reduce
the amount of especially in the memory
corruption
I mean if you switch to something like
rust even though I think on occasion
there's some rust core decays that shows
up where something doesn't get caught by
the verifier those are weird corner
cases in general yes I think you're
right if we switch languages the memory
corruption a lot of memory corruption
stuff goes away but not everything goes
away all the design stuff is still there
right so well so there was actually
there was a talk by Andre about sunny oh
yeah yesterday or day before where he's
doing a go runtime for and as a as a
base for an arm device so this is an
avenue that is currently in the
beginning of being researched and being
worked on I think it's interesting I
think it's a direction one that we could
go into I think there's something there
at the present time it still seems a bit
too early and the other thing is that
while it does reduce the you know number
of bugs that are going to be there in
particular memory corruption stuff it
doesn't like there will still be you
know your logic bugs and your heart
where bugs and things like that so it's
not a silver bullet but it could
definitely help okay and we out of time
please thank our speakers again
[Applause]
[Music]