About safety UEFI, part zero and first

Once upon a time, in early 2014, I called the security state of most UEFI implementations " semi-mythical ". Since then, a year and a half has passed, the case has been moving cautiously off the ground, but so far many PC manufacturers for the end user do not pay much attention to this very security - People hawala.
This article will discuss the threat model and attack vectors for UEFI, as well as the protection against overwriting the contents of the BIOS chip - the most destructive of the possible consequences of the attack.
If you are wondering how UEFI protection is arranged and what particular vulnerabilities in it remain uncorrected on most modern systems - welcome under cat.

Part zero. Introduction

I have been interested in the security of UEFI- compatible firmware for a long time, and I have been doing it professionally for almost 2 years. The reason for writing this article was the almost complete absence of any UEFI security information in the Russian-language part of the Internet, except for translations of articles by well-known English-speaking researchers made by people who are not very familiar with the subject. This gap should be gradually filled, because otherwise, it is filled with all sorts of slogans like “SecureBoot against free software”, “UEFI is a product of the devil” and the like. I apologize in advance for the language - when you do not speak for a long time and do not write in Russian, you stop thinking on it, and therefore the constructions can turn out to be very strange.

Threat model

Before we talk about security and vulnerabilities, let's talk a little bit about the threat model.
No protection can protect against everything at once. For example, the protection of the firmware from the destructive effect of a nuclear explosion or from failures when working in outer space, I will not consider in this article, although I would gladly read a similar article from experts in the relevant field.

Access levels

We define several levels of access for an attacker and see what and how successfully the “average” implementation of UEFI can counter to it:
- an attacker of the first level has physical access to the system, is able to load any OS, change UEFI settings, flash his UEFI code instead of the original one on the programmer, rearrange jumpers on the mat. circuit board, short circuit pins, etc.
- A second-level attacker has physical access to the system, but does not have a programmer.
- an attacker of the third level has remote access to the system in administrator mode.
The remaining cases will not be considered, since in UEFI, there is practically nothing to defend against a more powerful attacker who can change the chips sitting on the balls, and the weaker ones without administrator rights will stop the OS.
')

Attack vectors

Now we define the main vectors and the consequences of successfully completing an attack, in order of decreasing danger:

1. Storage of the main firmware (in 95% of modern systems - 1-2 NOR-flash chips with SPI interface)

The essence of the attack - insert your code into the firmware, delete parts of the existing one, steal, kill, keep silent about geese.
The consequences of an attack range from gaining full control over the firmware, hardware and operating system at best, to DoS at worst. A physical attacker can arrange DoS in any case (with a screwdriver swing into the board - that's what the DoS is for you), so I won’t dwell on the DoS for attacking first and second levels.

2. Code in SMM

Essence - we get access to a particularly privileged mode of the processor, from which we can read and write all physical memory and much more tasty.
The consequences are, at best, access to the firmware repository, and then see clause 1, at worst, bypassing the OS and hypervisor protection mechanisms (which, however, could be bypassed at the OS level, but from SMM this can be much easier).

3. PCI device firmware storage

Essence - we insert our code into the firmware of some PCI device (it’s Option ROM), for example, a network card or a Thunderbolt controller, UEFI executes this code when the device is initialized, ..., profit.
Consequences - at best, see point 1, at worst - almost the same thing, we only start much later, and therefore some things are already set up and blocked.

4. Variables in NVRAM

Essence - we get the ability to change UEFI settings, including hidden ones.
Consequences - at best, you can turn off all the protections and immediately go to step 1, at worst - again DoS (we write garbage in NVRAM, reboot, see what happens).

5. SecureBoot

Essence - we get the ability to download any desired OS, including UEFI Shell.
Consequences - at best, it is possible to load the UEFI Shell and immediately find yourself in step 4, at worst - to replace the standard OS loader with the modified one, thus securing itself in the OS, until the alert user turns SecureBoot back on.

Part one. Write protection in the main firmware repository

1. Hardware verification of the firmware or its part before executing any code

The most serious technologies in our list, which, being correctly implemented, protect the firmware from the attacking all three levels - Intel BootGuard and AMD Hardware-Validated Boot . Significantly differing in details, they perform the same task: they check the integrity of a small part of the firmware, which is signed by the motherboard manufacturer's EDS, and the key hash is flashed into the chipset. If the check is successful, the firmware starts, if not, it all depends on the settings. Both technologies provide a “hardware root of trust” for subsequent boot stages, and the firmware can build a chain of trust in which the chipset checks the bootstrap code, this code checks the PEI volume, which in turn is the DXE volume, and DXE already turns on SecureBoot and checks OS bootloader signature Any change to the parts of the firmware protected in this way most often leads to a commonplace DoS.
The reverse side of such protection is the impossibility of modifying the firmware even by a legitimate user of the system, the difficulty of repairing the motherboard if the chipset or SoC fails (and it’s good if we change it to a clean one and not to another one’s hash) Boot from the image, and the second will not help anything).
These technologies are supported since Intel Haswell and AMD Trinity, and I still don’t know what attacks are working on them, but now they are used on two and a half models of corporate laptops and I would prefer the situation not to change much, since it is the ability to modify the firmware and OS distinguishes your device from someone else.
How to check a particular system for any variation of the Verified Boot - I will write the next time after I receive permission to publish from Intel and AMD.
Attackers of the first level can relax and enjoy - in addition to hardware verification, they cannot be prevented by any of the subsequent defenses. That is why I said and I will say: the programmer and the SOIC-clip are a must-have for any serious researcher of firmware.

2. Read-only storage with hardware switch

In the old pre-UEFI times, on many motherboards, a jumper was installed to protect the BIOS chip from accidental or malicious firmware. There were practically no difficulties with the implementation of such protection, since All BIOS Setup contents were stored separately in CMOS SRAM and, except for firmware updates, there was simply no need to write anything. Then, someone at Intel made the decision that there is not enough space in the CMOS, and therefore you need to take the microcircuit more quickly and quickly, and write all the settings there, which is wasted time. As a result of this “ingenious” solution (and the following chains, the same level of genius), everything turned out to be in one chip: UEFI itself, part of the firmware of the integrated network card ( GbE ), most of the chipset firmware ( ME ), EC firmware and the devil knows what else , and each of the three owners of the microcircuit (CPU, ME and GbE) received the right to write to it not only during the update, but in general at any time. In order to somehow streamline the mess that has arisen, Intel added Flash Descriptor to the beginning of the chip, which explicitly states the access rights of three owners to each region ( I already wrote more about the descriptor and formats), but this did not help much. The only officially supported way to separate flies from cutlets and RW from RO is to install two SPI chips, the first goes to Descriptor, ME, GbE and NVRAM, and the second goes to the rest of UEFI, after which the #WP leg of the second chip sits on the ground, protecting the its recording is hardware.
There are several problems with such protection:
- two chips are a little less than twice as expensive as one and any purchaser wants to save them a million or two dollars on mass production, so a motherboard with two chips in the afternoon with fire cannot be found.
- physical access is required for the firmware, since The output of #WP to GPIO ruins all the security on the root.
- you can still spoil the contents of an RW chip without having any physical access.
Unfortunately, I have not yet seen the implementations of such protection on systems available on the mass market with UEFI. There used to be, but now they are left only on the Chromebook, but there the firmware is based on coreboot. I do not know how exactly the hardware protection against the firmware is implemented there, provided that there is the same ME as everywhere else ...

3. PR Chipset Registers

If the SPI hardware chip is not write protected, it can be protected by the chipset. All modern chipsets have at least 4 PR registers designed to protect against reading and / or writing a block of physical memory, because The SPI chip is always displayed on the “bottom” of the first 4 GB of physical memory (that is, the last byte of the SPI chip is always at the physical address 0xFFFFFFFF), but you can protect all or part of the firmware.
Protection of this kind is also not without problems:
- it needs to be implemented correctly, not forgetting that when you restart the values ​​of the registers are also reset, and they need to be restored.
- you need to remember to install (and restore after a reboot) lock on their configuration, otherwise the malicious code can trite them.
- protection cannot be disabled, i.e. updating the firmware from the OS without rebooting becomes impossible.
- and, of course, NVRAM and other RW areas cannot be protected in this way.
Unlike the previous paragraph, systems with PR'ami on the market the sea, and almost all protection is implemented illiterate or incomplete.

4.1. SMM_BWP and SpiRomProtect

Again similar to each other protection from Intel and AMD, respectively, which do not allow writing to the SPI chip from any processor mode except SMM. To upgrade the firmware, a special SMI handler is used, which must perform the integrity check and the signature of the new firmware, and only after successful verification do it run the firmware.
This protection is quite simple to implement and therefore there is almost any UEFI, but sometimes it is disabled by default. A big plus is the independence of the firmware code from architecture.
There are disadvantages:
- there is a lot of code in SMM, and any vulnerability in it gives full access to the firmware.
- from the bugs in the implementation of the driver itself, too, no one is insured.
- if protection is controlled by a variable in NVRAM (there are a lot of systems where this is the case), then it is practically useless, because it can be simply disabled by an attacker capable of downloading UEFI Shell.
Looking at the above disadvantages, the guys from Intel decided to fix them, somewhere around Ivy Bridge came up with the following protection, namely ...

4.2. Intel BIOS Guard, nee PFAT

Rightly judging that the code in SMM is too much, and IBV cannot write their flash drivers in any way so that they don’t have any holes, Intel decided that they needed to go deeper, and added another privileged execution mode, a special ACRAM memory area, inaccessible from other modes, in which you can download only the flasher that is signed by Intel's EDS, and only the SPI chip will have access to it. All three problems from clause 4.1 were successfully solved, but at the same time, of course, they added new ones:
- disgustingly high complexity in all. Scripts on your own DSL , signatures for each, separate update of components and other hell and Honduras.
- the image for updating cannot be flashed on the programmer, and to restore such firmware it is necessary to literally assemble it from the pieces, continually swearing.
- well, vendor lock-in, of course.
Some brave manufacturers use PFAT and it even works for them, but I tried and I can say - for any price, I’d better audit SMM code a couple more times than that.
I know nothing about attacks on PFAT, but the elusive Joe's rule most likely works here.

5. BLE and BIOS_WE

Long ago, when SMM_BWP was not yet, and the processor had one core, Intel had the write protection to the SPI chip as follows: there is a BIOS_WE bit that needs to be set so that the chipset allows you to send a write command. The bit is available to any code, so there is another bit next to it - BLE. If it is installed, the BIOS_WE installation generates SMI, and the BIOS registers the SMI handler, which is the BIOS_WE itself resets. The software sees that the bit is reset and stops trying to write - protection, that's all, it is impossible. If, however, flashing from SMM, then when installing BIOS_WE, there is no interruption (we are already in SMM), and you can sew.
As a result, all protection is based on the BIOS adding a processor and SMI will be generated, so for a successful attack, it was enough to forget the SmiLock bit so that you can turn off the source of this SMI and quietly sew anything you like. Then SmiLock ceased to forget and some IBVs were even sure that the protection was reliable, while on 31C3 Rafal Wojtczuk and Corey Kallenberg did not show that on multi-core processors the BLE / BIOS_WE mechanism is vulnerable to race condition, and the sense of it is almost zero, since The attack takes less than 10 minutes and is always successful.
However, still come across systems that are protected solely and exclusively by BLE. It is sad.

6. Missing

Textbook example of "patty without any." Some manufacturers of motherboards for desktops, we will not point with a finger, still do not protect the firmware from overwriting at all. Your system - you and bother, we do not give you any illusion of security, only bare BIOS, only hardcore. Behaving this way every day becomes more difficult, because on the one hand, Intel is pressured with recommendations, and on the other, Microsoft is pushing HSTI , but so far they are coping. Madness of the brave and all that.

Conclusion

With the protection of the firmware more or less figured out, in the next part we will talk about SMM and attacks on it .
I will be glad to any questions and comments. Thanks for attention.