Geekly Articles each Day
📜 ⬆️ ⬇️

About UEFI security, part three

We continue to talk about security UEFI.
This time we will talk about the serious vulnerability in the implementation of ACPI S3 (Sleep Mode), its operation and consequences, published at the end of 2014. The main "trick" of this vulnerability is that it revealed a whole class of UEFI security problems that were not considered at all before, and therefore deserves a separate article.
To those who have not read the previous articles of the cycle - once and twice , I suggest reading them first, waiting for the rest under the cut.

Part Three ACPI S3


Another little educational program
Unlike SMM , which the average user most often does not even suspect, is about ACPI S3, i.e. sleep mode, knows any owner of a laptop or PC, released in the past 10 years.
The ACPI standard, about changes in the latest version of which I recently wrote , defines a set of so-called. sleep states , one of which may be a system, as follows:

How S3 is implemented in UEFI
To restore the context during waking up, you first need to save it somewhere. At the same time, it is advisable not to become too attached to specific features of the processor and chipset architecture, and also to make the storage and restoration of the context as transparent as possible so as not to die later in debugging. Since S3 performance is a very important feature of almost any modern PC, with the exception of servers over the years uptime, the technology of preserving and restoring context was developed by Intel engineers very early, in 2004, and was named EFI S3 BootScript . Since then, the specification has been revised several times, the latest version is now in Volume 6 of the UEFI PI specification.
Its essence is as follows: after the execution of the PEI phase, in which the initialization of the basic devices takes place, i.e. processor, caches and RAM, the system determines the current boot mode.
1. If this mode is different from S3 Resume, the download continues as usual, PEI ends with running DXE Manager, which creates a new empty S3 BootScript and runs all available DXE drivers. Each such driver performs the final initialization of the device for which it is responsible, and then adds the commands to S3 BootScript that must be executed in order to re-initialize the device when returning from S3. The commands may be approximately the same (the list is taken from the PI 1.4 specification, but in specific implementations there may be non-standard ones):
The above commands are quite enough to reinitialize any device, especially considering the last command, which simply transfers control to the PEI driver, which performs all the initialization, but this is necessary only for particularly difficult cases when the rest of the commands did not work.
After the end of the DXE phase, the dispatcher stores the resulting S3 BootScript in AcpiNVS type memory , which contains ACPI tables and other data required by the OS for ACPI to work properly in it.
2. If, when booting, it turned out that the system is in S3 Resume, instead of the DXE manager, a PEI module with the beautiful name BootScriptExecutor runs, which executes the BootScript that has been carefully stored in memory since the past normal boot, and then transfers control to the OS that successfully starts and pleases the user.
Words, like, explained, now the same thing - a picture from the specification:


Underwater rake
It all worked successfully for about 10 years, and almost no one saw the catch until, at the end of 2014, the comrades Rafal Wojtczuk and Corey Kallenberg, well-known in narrow circles, did not present an attack , which turned out to be obvious and extremely dangerous at the same time. It turned out that the memory area (of the AcpiNVS type) that stores the S3 BootScript is not protected from modification. Yes, the OS perceives it as a service one and will not spoil the content on its own, but the attacker with administrator rights does not.
Modifications can be quite different, but because Most of the defense mechanisms that protect against arbitrary code in the SPI chip, as well as from unauthorized access to the SMM, are configured through the registers of the processor and the chipset, then to successfully bypass these mechanisms, it is enough to find the BootScript in memory (it is easy) to find in it we need the register (also no difficulties) and change it so that with the next S3 Resume protection could not turn on. We change, fall asleep, wake up - oops, and the king is naked! What threatens to remove the protection from the SPI chip and from the SMM - I already wrote in the last parts, I will not repeat, but it certainly will not end with anything good.
Interestingly, Intel engineers foresaw this attack and pre-implemented protection against it - the so-called. SmmLockBox . The protection is very simple - after the creation of the script is completed, it is copied entirely into SMRAM, while the original BootScript is not deleted. When restoring from S3, an SMI handler is called, which checks that the original BootScript matches the copy in SMRAM, and if it does not, either rewrites the modified BootScript copy or restarts the machine (this is safer, but the user loses all data from RAM). The problem turned out to be that SmmLockBox simply did not have time to implement it in time, and when Rafal and Corey tested the found vulnerability, it turned out that the only invulnerable to attack board was the Intel UOVI Development Kit.
After the publication of the attack, IBV began in a rush to introduce either the original SmmLockBox, or their counterparts based on the same idea, but this introduction often stalled for various reasons. For example, on systems with an AMD processor, SMM initialization was performed in the DXE phase, and therefore the call to the SMI handler from PEI with S3 Resume failed and S3 stopped working altogether.
However, at the moment, all vendors who have heard about security even with the edge of their ears have already solved this problem in some way, and if your firmware is newer than June 2015, and the manufacturer of your system is not an asshole - most likely your system will directly attack Changing S3 BootScript is no longer affected.

Pig from platform makers
After the panic subsided a bit, and BootScript was successfully shoved into SMRAM (it is clear that now it is necessary to keep it as the apple of one's eye, but I already wrote about this in the last part), it suddenly turned out that Intel and AMD engineers, without knowing it , put a decent pig in the face of their platforms on behalf of several PEI modules that were a ) copied into memory right next to BootScript, b ) were called from it by the DISPATCH command dozens of times and c ) were large enough for SMRAM to copy them not enough.
Thus, the execution of arbitrary code could be organized without modifying the BootScript itself in general, instead of modifying the entry point of one of these modules. It did not work to remove such modules without disrupting S3, but a solution was found - instead of copying to memory, they were transferred to the unpacked part of the DXE volume, and the DISPATCH commands were fixed so that the code was called directly from the SPI chip. This turned out to be a little slower than from RAM, but they managed to expel the pig. I do not know how many systems are now capable of attacking in this way, but I suspect that there are a lot of them.
')
Forgetful gentlemen
A person is not immune from errors, and the developers of DXE drivers are also human, and sometimes they can simply forget to write the addition of some important register in BootScript, and after S3 in this register will be its original value. Most often, such forgetfulness leads only to minor glitches after S3, but Murphy's laws tell us that if any important register can be forgotten, it will be surely forgotten, which is what happens. The last loud example of forgetfulness is a vulnerability in Apple laptop firmware published at the end of May this year, where engineers forgot to add an entry to PR registers in S3 BootScript, and after S3 the protection of the SPI chip from the firmware was removed by itself. It's very convenient, because I closed and opened the cover - and you can get the flashrom and write your code in the BIOS, Apple is happy again with simple and usability. If you think that there is a single case, I advise you to run the Chipsec utility on your PC and compare the reports made before and after S3. At the same time, a surprise can come out.

Disable S3 and the grass does not grow
Something like this, just more expressive and a bit more obscene, I exclaimed when I ran into a problem for the first time. Unfortunately, this option is not always possible (although S4 on the SSD differs little in speed, but it differs greatly in reliability, no dancing with scripts and executors is needed), moreover, if you did not turn off S3 tightly by modifying the firmware, the attacker can run on your system UEFI Shell, trite turn on S3 back. In the next part I will try to tell you how to avoid such an unenviable fate, but briefly - turn on and use SecureBoot, it is not at all evil, if you know how to cook it.

Trust crisis
The whole story with S3 BootScript revealed one interesting problem that after 10 carefree years of development at UEFI seriously began to solve just now. The problem is that the “secure” firmware can not trust anything that the OS has or had access to. Devices should be reset and initialized independently, memory should be cleared and no one should be used from it (do not let the code call the random from there!), Your Runtime services after the ReadyToBoot event cannot be used by the firmware components (they are already attacked by the attacker, sometimes several times), Generally, a solid minefield, a bit stumbled - and now you have a complete BIOS of someone else's code, there is no backdoor on the backdoor, there is no place for honest drivers in SMRAM. Therefore, platform manufacturers are looking for salvation in hardware solutions, someone is implementing a validated boot, someone is storing S3 BootScript in the Security Coprocessor, someone is developing his own cryptochip, someone is just scoring and is waiting for him to take the UEFI Forum solution from above will lower
Intel has also added an interesting SGX technology to Skylake, which can be used to isolate individual pieces of code and data from everything else in the system, an SMM analogue of its own, just for nothing, so that no one will leave offended. The technology looks quite tasty, but, firstly, it is difficult to program, and secondly - only Intel has it and only on Skylake.
From the side of the “safe” OS - the same level of mistrust to the firmware, and here the STM technology, which was discussed since 2009, can be useful, but it was officially presented only recently, and it has not been tested in “battle”. When hands reach both, I will try to write about it.

Conclusion


Well, the problems with S3 BootScript are behind, in the next part we will talk about attacks on NVRAM and SecureBoot, as well as why the BIOS password is from honest people.
According to a good tradition, I advise connoisseurs of English here this article Comrade. d_olex on the same topic. There is seriousness, depth, code, and pictures, not like my verbiage here.
Thank you for your attention, reader, safe for you firmware.

Source: https://habr.com/ru/post/267237/

More articles:


All Articles