About UEFI security, part four

We continue to talk about UEFI security, this time it will be about attacks on NVRAM and protection against them.
A seemingly good idea that the SPI chip can be stored settings almost forever, without relying on unreliable and battery-dependent CMOS SRAM, played a very bad trick on the UEFI developers. Now NVRAM is becoming more and more crowded with each new version of the standard. crutches and props, and the end of this process is not visible. If you are wondering what exactly they are trying to support with a crutch, this article is for you.
By tradition, anyone who has not read the first three parts for some reason - I recommend starting with them, I look forward to the rest under the cut.

Part Four NVRAM

Idea for minus a million

Honestly, I don’t know exactly who had the idea of ​​transferring the settings storage from CMOS SRAM, where it had been for centuries, to the main chip, but at the moment we can say that it was a bear service and hardware manufacturers, and the developer firmware, and end users. Apparently, Intel had its own reasons for it, and therefore the interface to NVRAM, represented by the four RunVeet services GetVariable / GetNextVariableName / QueryVariableInfo / SetVariable , became part of the very first published by Intel (which, prior to the organization of the UEFI Forum, worked on it almost exclusively a) EFI 1.10 standard, the progenitor of all current implementations of UEFI.

How does NVRAM work?

Logically, NVRAM (according to the UEFI specification) is a set of variables, each of which has a GUID (not necessarily unique), a name (in UCS2 encoding), attributes (about which below) and data that is stored in this variable itself.
By type, the variables are divided into normal (stored in RAM, they do not save values ​​when they are rebooted), NV (they are stored in the SPI microcircuit allocated for them, they are read from there when they are rebooted) and HR (they are stored in the SPI chip, but UEFI support to inform the firmware about detected hardware errors).
By access level, the variables were initially divided into two types - BS (not available after the OS started loading) and RT (always available), but with the implementation of the SecureBoot technology in the UEFI 2.3.1C standard, another 2 subspecies were added to the regular RT variables (for recording authentication is required) and TA (the same, only with a timestamp to protect against replay attacks).
The type of a variable is determined by its attributes, i.e. NV + BS + RT is a variable stored in the SPI chip that is readable and writeable both at boot time and from the OS. The standard also defines the rules for handling variables, for example, the presence of the RT attribute automatically entails the presence of a BS, and writing to variables without the NV attribute is impossible from the OS (all such variables become Read-only after the occurrence of the ExitBS event that ends the UEFI loader) .
Everything would be fine if the interface described above was the only one, and only he would be used to access the variables. Unfortunately, this is not quite true, and the HII driver, which provides the BIOS Setup menu to the user, practically bypasses the NVRAM driver, practically bypasses the NVRAM driver, so the NV-RAM storage format also had to be standardized, and now NVRAM is not stored in an SPI chip, but where something else is rather difficult.
The most well-known such “dual access” variable is Setup , which stores almost 100% (with the exception of passwords and a couple more things) of settings that can be changed from BIOS Setup. Its format is unique for almost every version and every system, but since the HII driver knows exactly what offset is the setting, and this knowledge is simply extracted when there is an image of the firmware using a pair of open source utilities, then it opens up the attacker with some potentially dangerous features.

Attacks on NVRAM

Forgetful gentlemen 2

Since For storage of NV-variables, an SPI chip is used, then for NVRAM operation, it is necessary to write into it while the OS is running, which immediately puts an end to protection using RO- microchips or PR- registers. Nevertheless, many system manufacturers still use PR registers, setting them up so that NVRAM falls into an unprotected write area, but at the same time they manage to completely forget that this area requires separate protection using the SMM driver for NVRAM and setting the SMM_BWP / SpiRomProtect bit. The result of forgetfulness is full access to all NV-variables regardless of the attributes, including SecureBoot variables that require authentication (which immediately makes the whole technology completely useless) and Setup (which allows you to sometimes disable the protection of the rest of the firmware and, after reboot, get full access to all the contents of the SPI chip), not to mention the banal DoS. The number of systems vulnerable to such a simple attack is amazing, for example, almost all Acer laptops are “protected” that way.
Another example of forgetfulness is to put RT on some important variable for debugging, such as Setup, and then forget this attribute to remove. The result - you can change the settings directly from the OS, it is very convenient, except that the whole SecureBoot is again under the tail.
')

Over the edge

One more attack, old as the world and simple as mooing - we write large variables in NVRAM, small variables, many variables, one hundred times the same variable, and so on and so forth, fluffy AFL to help you. Then we reboot and look at the reaction. The correct implementation of NVRAM with honor will respond to all unnecessary EFI_OUT_OF_RESOURCES requests and after rebooting everything will work, but do not count examples of any other outcome, when NVRAM just falls apart and the system gets a stake, not being able to continue downloading. Most often this results in a DoS, but if the attacker is very, very keen - see above.

UEFI loader strikes back

This attack is also not very new, about it in 2013 was a great post com. Falseclock . The essence of the attack is that the bootloader (for which you can use at least GRUB, even UEFI Shell, even any UEFI application in general) has the ability to execute arbitrary code before an ExitBS event occurs, i.e. The early stages of the bootloader have full access to BS-variables, including Setup. If the platform maker did not take care of prohibiting writing to this variable after the time window for BIOS Setup call ended (I saw such protection on exactly one industrial board, it is not found anywhere else), then the bootloader (or the user, if the bootloader has a shell ) can read and change the contents of the Setup variable, for the fifth time I will not write about the danger of this. The proposed protection against such outrageous bootloaders is SecureBoot, but with default keys it is suggested to blindly trust Microsoft (which promised IBV never to sign any shell loaders), and for those open source lovers who, in the default firmware, have the keys not only MS, but and Canonical, there is literally nothing to defend against this attack - the freshest GRUB2 build with a shell and other buns, signed with a Canonical key, can be downloaded directly from the Ubuntu repositories.
In conclusion, to the last part, I mentioned that the BIOS password is from honest people. I explain: it protects, most often, from unauthorized access to settings, and only to those that are accessible from the BIOS Setup interface. With the help of a suitable utility for accessing NVRAM ( Read Universal ), the parser of UEFI images ( UEFITool , PhoenixTool , uefi-firmware-parser ) and the parser IFR ( Universal IFR Extractor ) you can access all settings, including hidden ones, bypassing the password, and then also reset that same password when digging through the “hole in the fence” in the BIOS Setup will get bored.

Utilized Socialists

Finally, the most harmless NVRAM-related attack that a regular Linux efibootmgr utility can perform on your unsuspecting BIOS. Depending on the phase of the moon and the intensity of cosmic rays, sometimes with the next update of the nucleus, it can not only add another variable BootXXXX, but also remove several neighbors after that, and if this time, the rays are especially high-energy, that's all. After that, about 30 percent of the implementations of UEFI by Phoenix or Insyde fall into a complete stupor - still, the BDS phase is over, and there is nothing else to boot from. At the same time, all the possibilities to get out of the stupor, like BIOS Setup, were also among the very BootXXXX, and the user is forced to either use the Crisis Recovery subsystem (this is if he can in RTFM) or carry the system into service. Over the past couple of years, I personally encountered this attack four times on three fundamentally different systems. Stability, as they say, is a sign of excellence.

Best protection

It may sound paradoxical, but the best protection against all possible problems with NVRAM is the removal of NV from it, i.e. transfer of all variables on the chip SPI to RAM and setting write protection to the area with them using PR registers immediately after the BIOS Setup (if you do before - the settings will no longer be saved). The only modern OS that at least somehow uses the NVRAM entry is MacOS X, but they have their own amusement park without SMM and SecureBoot, so there’s a separate conversation about them. Windows and Linux are perfectly aware of the fact that the NV + RT variables no longer persist, only installers have problems (we write our bootloaders in BootXXXX, but they do not persist, sadness) and some very specific software (which is bleeding from the nose). variables are needed, but I have never seen such software). Neither the usual work with the OS, nor even the firmware update (or its individual components) using the Capsule Update mechanism, non-preserved NVRAM has practically no effect. You can’t think about it, but was it really necessary from the very beginning ...

Conclusion

The cycle is gradually coming to an end, it remains to tell about a couple of historical attacks on SecureBoot, about the danger of unsigned Option ROMs, and about outstanding gentlemen (and ladies), thanks to whom most of the described problems were discovered. Just a couple of parts is enough.
Thank you readers for your attention, good firmware, and remember - NVRAM should be protected from youth.