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!