WEBVTT
00:00:00.000 --> 00:00:18.070
36c3 preroll music
00:00:18.070 --> 00:00:27.750
Herald: Okay, let's go? You're ready?
Let's hand for Cyrevolt, please.
00:00:27.880 --> 00:00:31.260
applause
00:00:31.680 --> 00:00:36.400
Cyrevolt: Alright, hello everyone. I am
Daniel. You might have seen me before, I
00:00:36.400 --> 00:00:42.240
sometimes speak about open source
firmware. And at some point I also had to
00:00:42.240 --> 00:00:48.560
start to look into more specific stuff. So
this talk here is about the Intel
00:00:48.560 --> 00:00:54.160
Management Engine, sometimes also known as
the unmanageability engine, it always depends
00:00:54.160 --> 00:00:57.920
on, you know, what website you find or
what person you ask, you might get either
00:00:57.920 --> 00:01:08.720
response or both. So let's see. A little
disclaimer first: I am not trying to blame
00:01:08.720 --> 00:01:14.560
Intel for anything they have done, or
something. This year is not about whether
00:01:14.560 --> 00:01:20.400
we can trust Intel as a company or any
other chip vendor or vendor in general,
00:01:21.440 --> 00:01:27.520
because I cannot read their minds. I don't
know their intentions. What we can only do
00:01:27.520 --> 00:01:33.760
is see what they put out in the public or
what we find in the machines that we buy.
00:01:37.760 --> 00:01:43.440
And on the other hand, we don't really
know that much because especially with the
00:01:43.440 --> 00:01:49.120
Intel ME there is not very much public
information. So people try to figure
00:01:49.120 --> 00:01:54.800
things out, there are forums, there are
certain small projects, like analysis
00:01:54.800 --> 00:02:02.160
tools and stuff, but all of these are
based on reverse engineering or educated
00:02:02.160 --> 00:02:10.080
guessing or whatever people could just
figure out. And me especially I don't know
00:02:10.080 --> 00:02:15.200
very much about it, actually. So I'm just
here because I'm interested in the field
00:02:15.200 --> 00:02:20.880
and at some point there was an event which
made me look into it, but more about that
00:02:20.880 --> 00:02:28.560
later. The agenda for today: I will give a
very brief introduction, it will be a very
00:02:28.560 --> 00:02:36.240
bold introduction, though, into the entire
field around firmware, then I will be
00:02:36.240 --> 00:02:43.520
switching over to the open source firmware
stuff we do, I will briefly try to explain
00:02:44.320 --> 00:02:53.600
the hardware we know as Intel's x86
platforms, then I will try to give you a
00:02:53.600 --> 00:02:57.840
motivation to also look into what I have
been looking into and tell you what made
00:02:57.840 --> 00:03:04.960
me look into it, I will give you some
entry points for analysis, and eventually
00:03:04.960 --> 00:03:12.730
we will just get a conclusion and start to
think about what we just heard. So for the
00:03:12.730 --> 00:03:18.800
introduction: Who of you in the audience
has already done something with
00:03:18.800 --> 00:03:25.680
microcontrollers? Please raise your hands.
Okay, we see lots of hands here. And in
00:03:25.680 --> 00:03:30.000
fact we actually have like hundreds or
thousands or millions of microcontrollers
00:03:30.000 --> 00:03:38.640
here, right, so all the lights we see over
here, there are ESP8266, that board, you
00:03:38.640 --> 00:03:45.120
see in the middle there's Arduino and
there's something which I like to call NOT
00:03:45.120 --> 00:03:48.800
- the network of things, because
apparently you just need a network you
00:03:48.800 --> 00:03:53.040
don't really need the Internet for it. And
we can connect all of those devices. We
00:03:53.040 --> 00:04:00.160
can remotely control them. And I'm now
going to show you, that what you have in
00:04:00.160 --> 00:04:10.663
your laptop is actually the very same
thing. Now this is lots of bullet points,
00:04:10.663 --> 00:04:16.664
and I'm very sorry for it, but this gives
you a feeling of what we are dealing with
00:04:16.664 --> 00:04:25.280
here. In your laptop you have multiple
such controllers which are very similar to
00:04:25.280 --> 00:04:32.400
the Arduino or ESP microcontrollers that
you already know. Some of them are for
00:04:32.400 --> 00:04:38.480
very, very specific functionality - so
everyone knows the USB controllers, we
00:04:38.480 --> 00:04:46.160
have USB controllers, we have PCI, where
other devices are connected, we have GPUs,
00:04:47.600 --> 00:04:56.560
we have a whole lot more. But the very
core - that's what is known as the chipset
00:04:57.200 --> 00:05:05.200
and the CPU. It can sometimes also be one
single chip, like in this graphic here,
00:05:05.200 --> 00:05:10.240
which I have borrowed from Intel - just
adjusted the colors a bit to make it fit
00:05:10.240 --> 00:05:14.400
with the slides - and here you can see
lots of lines connecting all of those
00:05:14.400 --> 00:05:22.000
controllers. Now there's some other
controllers which I also started to look
00:05:22.000 --> 00:05:28.080
into. They are called the embedded
controller which is an additional
00:05:28.080 --> 00:05:35.200
microcontroller on your laptop for power
management, for controlling the charging
00:05:35.200 --> 00:05:41.840
circuit. When you connect your charger to
your battery you will see an LED, that's
00:05:41.840 --> 00:05:45.760
what this device is doing. It might be
connected to a keyboard, to your mouse.
00:05:47.120 --> 00:05:53.120
And there is a very similar concept also
for servers. It's called BMC or Baseboard
00:05:53.120 --> 00:06:00.480
Management Controller. It's purpose is to
remotely control a server, so you don't
00:06:00.480 --> 00:06:05.200
have to actually go to a data center.
Imagine you're administrating 5 data
00:06:05.200 --> 00:06:09.920
centers all across the world, you can't
literally be in all of them at the same
00:06:09.920 --> 00:06:15.600
time. So that's why they came up with an
interface to remotely control it and
00:06:15.600 --> 00:06:20.480
they've made a dedicated chip for it which
is also connected to many devices on the
00:06:20.480 --> 00:06:25.940
server platform. Then there is one thing
you might also have heard about: a so
00:06:25.940 --> 00:06:33.920
called TPM - a Trusted Platform Module -
and it's main purpose is to give you a
00:06:33.920 --> 00:06:40.160
very small trust anchor from which you can
run all of your top-level applications,
00:06:40.160 --> 00:06:47.200
below which is an operating system, which
is actually running after a bootloader,
00:06:47.200 --> 00:06:51.200
which is actually started from your
firmware, which is actually loaded from
00:06:51.200 --> 00:06:59.280
your chipset. And that's how deep the
rabbit-hole goes. Now let's look at open
00:06:59.280 --> 00:07:08.640
source projects. We have projects for all
sorts of features around the CPU. The CPU,
00:07:08.640 --> 00:07:15.360
before your laptop can even start up, it
has to be initialized. It also has to know
00:07:15.360 --> 00:07:20.640
the RAM. When you boot up a machine it
doesn't yet really know anything about
00:07:20.640 --> 00:07:29.885
RAM. That's what the coreboot project is
doing. Now today we have a bit of a
00:07:29.885 --> 00:07:35.801
problem, because we don't have enough
information to actually program coreboot
00:07:35.801 --> 00:07:43.960
for modern machines. So there is a
different approach now. You know the UEFI
00:07:43.960 --> 00:07:52.466
or Unified Extensible Firmware Interface?
It's a bit of a different approach also to
00:07:52.466 --> 00:07:58.284
initialize hardware but also to hand over
to an operating system. But the thing is
00:07:58.284 --> 00:08:02.095
there is lots of drivers in there and
stuff. So we want to replace that with the
00:08:02.095 --> 00:08:06.068
Linux kernel - that's what the LinuxBoot
approach is doing - there're different
00:08:06.068 --> 00:08:12.355
implementations - there is Heads, there is
u-root. And that's how we can start modern
00:08:12.355 --> 00:08:18.916
machines with a bit more knowledge. For
embedded controllers we have the projects
00:08:18.916 --> 00:08:24.438
from Google for the Chromebooks. There's
lots of open source implementations but
00:08:24.438 --> 00:08:29.287
they only apply to very specific hardware.
You could find all of those stuff on the
00:08:29.287 --> 00:08:35.823
web of course. And, then System76 is also
currently working in that field for their
00:08:35.823 --> 00:08:43.600
laptops, and eventually for the BMCs I
just introduced you to, there is also two
00:08:43.600 --> 00:08:51.520
projects there is the OpenBMC project and
the euro project. Okay, so that's how far
00:08:51.520 --> 00:08:56.720
we are, but that's not what I'm talking
about today, I'm talking about something
00:08:56.720 --> 00:09:06.240
else. And that's why we have to take a
closer look at Intel x86 hardware. This
00:09:06.240 --> 00:09:11.840
here is an example of a platform which has
a dedicated chipset and a processor.This
00:09:14.960 --> 00:09:20.240
is also a graphic I borrowed from Intel,
once again. It shows you where all of
00:09:20.240 --> 00:09:26.720
those peripherals are connected, so,
again, we have USB, we have Ethernet, but
00:09:26.720 --> 00:09:32.960
there is more to it, actually. And, you
can clearly see that this chipset here,
00:09:32.960 --> 00:09:38.720
it's quite a large box and there is a
reason for it, because that's where
00:09:38.720 --> 00:09:46.000
actually most of the chips are connecting.
That's why Intel calls it the Platform
00:09:46.000 --> 00:09:53.280
Controller Hub, or a PCH for short. Now
let's look closer at the Denverton
00:09:53.280 --> 00:09:58.240
platform. Denverton is one of those model
names for the platforms - Intel always
00:09:58.240 --> 00:10:05.200
comes up with these names and here we have
a very brief summary of what peripherals
00:10:05.200 --> 00:10:11.840
we have and if you look very closely in
the upper right corner, there is two so-
00:10:11.840 --> 00:10:20.000
called engines mentioned: one of them is
the Innovation Engine, the other one is
00:10:20.000 --> 00:10:24.788
the Management Engine, which we're dealing
with today. The Innovation Engine has a
00:10:24.788 --> 00:10:32.447
very brief description, it says it's
something about innovation, it's something
00:10:32.447 --> 00:10:37.067
about firmware, but actually I have not
yet found any use for it but it's there in
00:10:37.067 --> 00:10:41.829
your hardware. So if you have a Denverton
chip in your laptop, or wherever you might
00:10:41.829 --> 00:10:47.145
find it, you have some features there but
I don't know what they are for. Okay, so
00:10:47.145 --> 00:10:53.560
let's look at the Management Engine,
today. Because the thing is: Hardware is
00:10:53.560 --> 00:11:01.560
evolving. The Management Engine today is
not the Management Engine from a few years
00:11:01.560 --> 00:11:07.266
ago. So with new hardware we get different
chips over time, the y are attached to
00:11:07.266 --> 00:11:13.836
different other peripherals over time, and
they're given different purposes. So
00:11:13.836 --> 00:11:21.511
basically the ME itself is just a
microcontroller like Arduino and it's part
00:11:21.511 --> 00:11:28.072
of your chipset. If you have a combined
chipset and main processor, it's in that
00:11:28.072 --> 00:11:32.544
one single chip and that's where it is.
But that's not where it started. It
00:11:32.544 --> 00:11:39.639
actually started as the so called Active
Management Technology. The idea was that
00:11:39.639 --> 00:11:45.451
you could remotely control a device and
provision it, just like what I described
00:11:45.451 --> 00:11:51.964
you as the Baseboard Management Controller
for servers. It's the same thing but for,
00:11:51.964 --> 00:11:57.360
let's say, laptops, desktop PCs. Imagine
you're running a very huge company and you
00:11:57.360 --> 00:12:02.560
have hundreds of devices to maintain. Now,
you have to this BMC thingy for servers
00:12:03.200 --> 00:12:06.832
and this thing here for your desktop
devices. Now the question is: why is it
00:12:06.832 --> 00:12:16.634
actually connected to all of those
peripherals? First of all there was a bit
00:12:16.634 --> 00:12:24.865
of a renaming recently: it's no longer
just called the ME, it's called the CSME:
00:12:24.865 --> 00:12:33.100
Converged Security and Manageability or
Management Engine. It can load your
00:12:33.100 --> 00:12:40.120
firmware and verify it and with that
firmware we are now talking about the host
00:12:40.120 --> 00:12:46.423
CPU firmware. That thing that coreboot can
be doing or what your vendors UEFI
00:12:46.423 --> 00:12:54.324
firmware is doing. If that firmware is not
as expected, which means it's not signed
00:12:54.324 --> 00:13:03.235
with a certain key from either Intel or
your OEM, the equipment manufacturer which
00:13:03.235 --> 00:13:12.144
can be HP or Asus or whatever, then your
laptop might not boot. That's a feature
00:13:12.144 --> 00:13:19.960
it's a security feature. Now the problem
is: if we want to legitimately replace the
00:13:19.960 --> 00:13:26.515
firmware with our own implementations we
can't do it. If this certain feature is
00:13:26.515 --> 00:13:31.802
activated. It's also known as boot guard.
But, again, this is not what we're talking
00:13:31.802 --> 00:13:41.525
about today, I want to look at something
else. This here is how your machine boots
00:13:41.525 --> 00:13:49.636
up: On the left-hand you see the flow I
just described you, what the ME is doing.
00:13:49.636 --> 00:13:55.228
You press the power button on your
machine. The ME is coming up, it's
00:13:55.228 --> 00:14:01.672
initializing itself first with its own
firmware, that's the RBE-phase - a bit
00:14:01.672 --> 00:14:10.400
more about that later. Then there is a
bringup phase, which hands over to the ME
00:14:10.400 --> 00:14:16.000
operating system, if that version of your
ME actually has an operating system, which
00:14:16.000 --> 00:14:25.760
is not necessarily the case. It will reset
the CPU itself. It will trigger the
00:14:25.760 --> 00:14:32.000
firmware on the CPU to start, that's where
coreboot could take over or your vendors
00:14:32.000 --> 00:14:39.120
UEFI firmware, it notes some microcode
updates, it comes to the initialization
00:14:39.120 --> 00:14:44.720
phase where you get RAM and the CPU and
eventually all the features you have in
00:14:44.720 --> 00:14:51.600
your chipset itself, until you can boot
your host operating system. Now at the
00:14:51.600 --> 00:14:56.720
same time there is two more chips even
being powered on: one is the PMC, the
00:14:56.720 --> 00:15:02.000
Power Management Controller, which also
gets some updates or patches from the ME
00:15:02.000 --> 00:15:07.040
firmware, and the EC, the Embedded
Controller, I already described you, which
00:15:07.040 --> 00:15:15.520
is just running in parallel. But in fact
these are all connected to each other. And
00:15:15.520 --> 00:15:20.480
here's some of the features summarized
which we have in ME: so the Active
00:15:20.480 --> 00:15:25.040
Management Technology is implemented for
example in the Linux kernel, there is a
00:15:25.040 --> 00:15:33.040
driver for it. It could do hardware
monitoring, it can monitor if your chips
00:15:33.040 --> 00:15:40.240
are overheating, it can have other sensors
connected to it, it can do power control,
00:15:40.960 --> 00:15:44.800
that's why I just described you, just like
a BMC you can power cycle your system
00:15:44.800 --> 00:15:49.920
through it. You could update your
operating system out-of-band, so not like
00:15:49.920 --> 00:15:55.280
using apt-get upgrade or something. No,
instead you would just do it from outside.
00:15:57.520 --> 00:16:03.600
So you could reformat an entire disk,
replace it with a new image. You have a
00:16:03.600 --> 00:16:09.840
bit of storage and you even have a proxy
for a keyboard and mouse and the video
00:16:09.840 --> 00:16:16.640
interface, so it's like VNC literally.
That's what we know from the public
00:16:16.640 --> 00:16:23.520
documentation. Now the interface that is
implemented in the Linux kernel has been
00:16:23.520 --> 00:16:29.840
extended a bit. Now we have a dedicated
chip, which was pulled out of the ME, the
00:16:29.840 --> 00:16:35.920
ISH, or Integrated Sensor Hub. It just
does the very basic things I just
00:16:35.920 --> 00:16:39.838
described you about sensors just in a
dedicated chip. That's a good development
00:16:39.838 --> 00:16:45.390
actually because now we don't have a
single point of failure which has
00:16:45.390 --> 00:16:51.012
everything, we have a single point of
failure which has everything but this
00:16:51.012 --> 00:16:58.359
part. There is BIOS extensions. In your
host firmware there can also be certain
00:16:58.359 --> 00:17:06.095
libraries or drivers which are connecting
to the ME. You can control the ME through
00:17:06.095 --> 00:17:13.036
it. If you have a business laptop you
might be running the corporate version of
00:17:13.036 --> 00:17:19.425
the ME firmware and then you might press
F6 or Ctrl+P when booting up, and you
00:17:19.425 --> 00:17:25.760
might get a prompt. If you are still in
the manufacturing mode or you just bought
00:17:25.760 --> 00:17:30.128
the machine very fresh, just type "admin"
that's the default password - that's
00:17:30.128 --> 00:17:34.840
publicly documented by the way it's not
something I found somewhere but in Intels
00:17:34.840 --> 00:17:40.015
own documentation. And then you can start
using that feature. So this might apply, I
00:17:40.015 --> 00:17:45.202
haven't confirmed it, but it might apply
to the HP EliteBooks for example which are
00:17:45.202 --> 00:17:50.180
for business use or certain Lenovo
ThinkPads from the T-series. You could try
00:17:50.180 --> 00:17:59.200
it on your machines, maybe. Now I've
already described you that there are lots
00:17:59.200 --> 00:18:05.840
of different variants and versions of the
Management Engine. We have a very, very
00:18:05.840 --> 00:18:11.200
long timeline here, we are talking about
years starting from 2004 until now, so
00:18:11.200 --> 00:18:20.720
it's 15 years since the Active Management
Yechnology was announced until today where
00:18:20.720 --> 00:18:25.238
we have version 12 of the Management
Engine. The problem with this timeline
00:18:25.238 --> 00:18:32.734
here is, again the disclaimer, I cannot
really verify all of this information. I
00:18:32.734 --> 00:18:38.083
have mostly gathered it from different
sources, so don't take all of this for
00:18:38.083 --> 00:18:43.294
granted. Some of this might also just
include some educated guessing from my
00:18:43.294 --> 00:18:48.972
side. If you find any errors, you will get
the links later, you can file me bugs or
00:18:48.972 --> 00:18:54.410
send your pull requests. So we're at
version 12 now. For each version of the
00:18:54.410 --> 00:19:00.307
Management Engine there's release notes,
they are public. So in ME 12 they just
00:19:00.307 --> 00:19:08.171
dropped version 1 for TLS, 1.2 is now in
and we have a few other features. Some of
00:19:08.171 --> 00:19:11.311
them I don't even know but you can look it
up on Intels documentation. Those are the
00:19:11.311 --> 00:19:22.520
variants we already know, consumer,
corporate, a slim version apparently,
00:19:22.520 --> 00:19:28.283
there's the SPS version which was made for
servers and now there is something called
00:19:28.283 --> 00:19:36.880
Ignition. Which actually brings us to our
motivation here. This is an email from the
00:19:36.880 --> 00:19:44.160
EDK to non-osi mailing list. They
announced a version of the ME binary which
00:19:44.160 --> 00:19:48.880
can finally be distributed. So you can
give it to other people. You couldn't do
00:19:48.880 --> 00:19:54.400
that before. Well, at least not
officially. Of course when you get
00:19:54.400 --> 00:19:59.840
firmware updates from your supplier, you
get those binaries in a way, but it's not
00:19:59.840 --> 00:20:05.840
like you download them from Intel
directly. Which means that now we can
00:20:05.840 --> 00:20:12.800
offer full images of custom firmware based
on coreboot, based on this ME binary here
00:20:13.440 --> 00:20:22.720
and whatever we want to tailor it for. So
let's follow the yellow-brick road. This
00:20:22.720 --> 00:20:30.800
is the license. The license allows
basically only redistribution, you may not
00:20:30.800 --> 00:20:37.040
make any changes, you may not reverse it,
you may not decompile it, you may not
00:20:37.040 --> 00:20:42.720
disassemble it. Now how do we actually
verify, that it works as desired and as
00:20:42.720 --> 00:20:48.560
promised? Pay no attention to the man
behind the curtain! If you have seen The
00:20:48.560 --> 00:20:55.013
Wizard of Oz, you know the scene. That's
literally what they want. Their philosophy
00:20:55.013 --> 00:21:04.640
is kind of a shallow thing, so they don't
really want to be very open with
00:21:04.640 --> 00:21:09.680
information. This here is from a training
slide, it's an official training that
00:21:09.680 --> 00:21:14.560
Intel is giving at certain events. They
tell people: "Well, we have lots of
00:21:14.560 --> 00:21:18.560
firmware developers, we want to support
them in a way, but not too much actually."
00:21:21.920 --> 00:21:28.080
I have to be a bit quick because I have
more slides than time.Here's the vendor's
00:21:28.080 --> 00:21:32.560
perspective from Intel's FSP white paper.
FSP is the Firmware Support
00:21:32.560 --> 00:21:39.680
Package.They're saying they're working
towards, well, releasing something, but
00:21:39.680 --> 00:21:43.920
actually not. So if you have a binary and
it works as desired then it's okay,
00:21:43.920 --> 00:21:50.320
otherwise, well, not so much but they
promise it works. And the same applies for
00:21:50.320 --> 00:21:56.640
ME, I guess. Which is where Dexter's law
applies, which is saying that only
00:21:56.640 --> 00:22:04.000
proprietary software vendors actually want
proprietary software. And now that's the
00:22:04.000 --> 00:22:08.640
issue, if somebody is attacking your
system, they do not play by the rules.
00:22:11.040 --> 00:22:15.141
Let's take some first steps into that
direction. There are some analysis tools,
00:22:15.141 --> 00:22:21.330
there's the me_cleaner, MEAnalyzer and
more. There has been some reverse
00:22:21.330 --> 00:22:26.109
engineering, not from my side, because of
course the license doesn't allow it. More
00:22:26.109 --> 00:22:30.628
information can be found in other talks.
There was the Plundervolt attack, just
00:22:30.628 --> 00:22:38.161
recently, which was actually based on
reverse engineering. And now I'm afraid I
00:22:38.161 --> 00:22:41.879
have to cut it here. We have security
issues. We want to analyze firmwaer.
00:22:41.879 --> 00:22:54.205
Here's a bit of data structures, I will
just briefly skim through those now. You
00:22:54.205 --> 00:23:03.920
can approach me later for more. And I want
to briefly come to this conclusion because
00:23:03.920 --> 00:23:08.960
this is the important part. So for
security all firmware has to be open
00:23:08.960 --> 00:23:17.040
source. Here's the list of acronyms, some
other talks to refer to again. Thanks to
00:23:17.040 --> 00:23:20.800
everyone who has actually helped me with
this, that's all the hacker spaces, I hang
00:23:20.800 --> 00:23:25.600
out at, the Chaos West team and the stage
here, of course, and the open source
00:23:25.600 --> 00:23:30.720
firmware projects. Please come to our
assembly, it's right over there, if you
00:23:30.720 --> 00:23:39.680
want to know more. So thanks, first. If
you have any questions, please approach me
00:23:39.680 --> 00:23:45.520
now or, well, just in a bit at the
assembly. I guess we have time for one
00:23:45.520 --> 00:23:49.415
very small question, now.
Herald: Yeah, thank you very much, let's
00:23:49.415 --> 00:23:53.105
have a hand.
Applause
00:23:53.105 --> 00:24:00.658
Herald: There'll be two mics, they're lit.
We have time for one question or maybe two
00:24:00.658 --> 00:24:08.553
but short ones. Anybody has a question?
No? About all the fun you can have and not
00:24:08.553 --> 00:24:21.280
supposed to have. Okay. Thank you very
much. Okay, in which case let's close it
00:24:22.640 --> 00:24:30.470
and take your trash, please, and be
excellent to each. Thank you very much.
00:24:30.470 --> 00:24:33.573
Applause
00:24:33.573 --> 00:24:35.720
36c3 postroll music
00:24:35.720 --> 00:24:59.000
Subtitles created by c3subtitles.de
in the year 2020. Join, and help us!