Understanding The Intel CSME CVE-2019–0090 Vulnerability for Mere Mortals

8 min readMar 10, 2020

A couple of days ago, it was all over the news that a new vulnerability was found in the Intel Management Engine. Although the vulnerability hasn’t been fully disclosed yet, it made it into many headlines that this vulnerability is unfixable with a firmware update, with several news sources reporting that Positive Technologies was saying that this has the potential to destroy the whole Intel security model.

Other than that there hasn’t been much reporting about the vulnerability and when I checked the Positive Technologies blog post they seemed to be very timed about the issue, however, the more I researched trying to understand the exact problem the more I kept finding that this is a pretty huge exploit and that probably because of its complex nature and the technical details required to understand the exact problem it hasn’t had enough mainstream news coverage.

This blog post is my attempt to try to explain what exactly is going on and what kind of effects this might have in the next couple of weeks.

The Intel Platform Controller Hub

A couple of years back, Intel decided to add several functionalities that were required to operate their CPU’s to a separate hardware module called the Platform Controller Hub (PCH) these functionalities included some power management stuff, I/O control and more relevant to us what is called the Intel Converged Security and Management Engine.

The Intel CSME is a small System On a Chip with its own 486 based CPU, RAM, and ROM, and even Minix based OS.

The goal of this CSME was to provide various security-related functionalities to the main Intel CPU, some of these were

Firmware Verification (To make sure that the software that is running inside the Intel CPU or Intel Chipset is coming from Intel).
UEFI verification to make sure that it’s coming from your devices OEM.
Functionality to allow for full disk encryption technologies like BitLocker.
Functionality relevant for Enterprise management systems (e.g., Remote Monitoring).

The two issues that many security researchers had with the Intel CSME was that first; it had a closed source firmware that Intel distributed as a binary blob and second, that this firmware had complete access to your system’s memory, I/O and network interfaces the three things an attacker would need to have untethered access to your system.

Privacy and Open Source advocates also had an issue with having firmware running on your system without knowing what it’s doing. Add that to the fact that Intel now could blacklist specific software from running on your system, and you can see why many people were skeptical about the CSME.

Regardless of your security or privacy stance or if the presence of the CSME was justified or not, this unequivocal access to the system is why most engineers refer to the software running inside the CSME as operating in God Mode.

To understand this presumed attack on the Intel CSME by Positive Technologies, we need to do a refresher on some underlying computer architecture 101's.

MMU, DMA and the IOMMU

Memory Management Unit (MMU)

The main idea behind the MMU is that with the help of the operating system it makes each program believe that it has access to the complete memory of your system, it does so by giving each process virtual address space (of a size predefined by the operating system) and then performing a mapping between this virtual memory to the actual physical memory on the system.

So while a web browser might think it’s accessing location 0x0000001 in the memory, in reality, it is accessing a random physical location (e.g., 0x0022e3244).

This has the side benefits of

Performing memory isolation, so one process, a game, for example, can’t access the credit card information you’ve entered in another process though they’re both loaded in memory.
Having special protected memory zones (kernel memory and user space memory)

Direct Memory Access (DMA)

The theory behind the DMA is basically as its name implies giving direct memory access to different devices without interrupting the CPU.

A while back, when CPU’s where relatively slow when a device wanted to access memory, it had first to ask the CPU. Then the CPU would yield this access to the memory; when CPU’s got a lot faster, it became evident that this is a waste of valuable CPU time, and another module called the DMA controller was developed to do this job. It would act as another master on the memory bus and would be able to grant memory access to different devices without bothering the CPU.

The next question now is who would prevent a specific device from basically overwriting or reading unauthorized memory locations, for example, what would prevent your graphics card firmware from reading your credit card information or your operating systems secrets.

This gave rise to the IOMMU, which acts as an MMU, but instead of regulating memory access to applications and processes, it regulates access to devices so that each device can only see memory locations relevant to its work.

A very salient detail when building a secure system is when do you initialize the IOMMU module because if you initialize it after a malicious device (a malicious USB Flash stick for example) is loaded that means that for a specific time frame (between the USB Flash stick finished initialization and the initialization of the IOMMU) the memory of the system is still vulnerable to manipulation.

What is interesting is that Apple highlighted this problem when introducing the T2 secure chip as one of the challenges when implementing a security system. (The solution was to do a dummy initialization at the beginning of the system boot that would disable all DMA access).

Intel CMSE

Now that we have enough of a background, let’s dive into the architecture of the Intel CSME itself.

**Intel Converged Security and Management Engine**

We need to look at the CSME as a small computer all of in itself; it has a CPU based on 486, RAM, ROM..etc.

Besides that, it also has a couple of interesting blocks

Manageability Devices

The manageability devices are a bunch of interesting devices; they contain devices ranging from the Intel Firmware TPM that is used as a basis for other technologies such as Bit Locker and SecureBoot and other Enterprise monitoring devices allowing keylogging, screen-capture..etc.

The fact that this block alone could be compromised is extremely alarming because it means that an attacker could have complete control of the system without any ability for the operating system even to detect not to mention stop the attack.

The Minute IA System Agent (MISA)

The System Agent performs other functionality, but the one we’re interested in is the IOMMU, as explained earlier, the IOMMU manages the DMA access from other components in the CSME to the SRAM.

Gasket

This is the interface of the CSME to the outside world.

Crypto Engines

These are several HW blocks that accelerate the different encryption/decryption algorithms.

The Boot Sequence of the CSME

According to publicly available Intel literature, the CSME starts executing from the ROM, and this is considered the Root Of Trust of the system, the ROM has several interesting properties

It’s completely read-only, once it’s burned at the silicon fabrication stage, it can never be overwritten again¹.
Because this memory is read-only, it’s extremely dangerous to have software running from it, because even if you find a non-security related bug inside that code, Intel would not be able to fix the issue until a new chip is manufactured. This gives an incentive to do the extreme minimum amount of initialization in the code running from this ROM.

After the code in the ROM is executed, there is a jump to the code in the RAM, which continues initializing the rest of the HW and loads the OS used inside the CSME.

The Presumed Vulnerability

If we look closer at the boot sequence, we can catch a pretty error-prone scenario.

What happens if some device could access the SRAM using the DMA before the processor finishes executing the code in the ROM, wouldn’t it allow the attacker to inject code in the RAM that will be called from the ROM code?

This, of course, depends on several points being valid

The first is that the DMA devices could access the SRAM while the device is running from the ROM (remember that this was the whole idea behind DMA, to begin with)

The second point, and this is the tricky part that the IOMMU would allow this kind of access. Remember that during the ROM execution the different parts of the HW are still uninitialized, so they’re operating in their default state however if the default state of the IOMMU is to allow DMA devices to access the whole memory (spoiler alert Positive Technologies says that it does) it would simply allow the attacker to load his code to be executed in the RAM.

Closing Points and Remarks

Several points are worth noting though

Apple not only managed to circumvent this whole problem by using their T2 chip as the root of trust, but they’ve also publicly addressed a similar issue (instead of inside the Intel CSME, the problem was with the main CPU’s IOMMU).
The sneak peek from Positive Technologies didn’t mention what device they used to access the SRAM inside the CSME., they did, however, mention that the vulnerability is available in both local and physical system access, this probably indicates that there are multiple attack vectors in place.
According to my current understanding, an important point to consider is that once a device is hacked and the security keys are either extracted or modified, this device could no longer be safe again.
To be fair to Intel, they have been quite open about the architecture and design of the Intel CSME.
Other CPU manufacturers have similar technology (AMD has their Platform Security Processor).

In the next couple of weeks Positive Technologies will be releasing their white paper, and we’ll have a lot more information about the exact details of the attack, but until now they seem to be extremely conservative about the repercussions of this vulnerability, So far they are correct that this completely invalidates every security mechanism in every single processor with the Intel CSME.

Disclosure

A couple of years back, I used to work for Intel as a Validation Engineer. However, I was never involved in any work related to the Intel CSME or any other topics mentioned in this post. This post was based entirely on public information found in the reference section.

Please note that this article is based on a day’s research about how the Intel CSME works and the available information from the Positive Technologies blog post. The main goal was to provide easy to grasp information about the attack; I might have skipped or been extremely loose about how specific components work.

However, if you do find incorrect information regarding the attack, please contact me so I can correct it.

References

Footnote

Even during development, the only way for Intel engineers to resolve bugs in the boot ROM is to enable a ROM bypass fuse that is only available during development that would skip the whole code in the ROM.