UEFI Security Part Four

We continue to talk about UEFI security, this time we will focus on attacks on NVRAM and protection against them.
The seemingly good idea that settings can be stored on the SPI chip almost forever, without relying on the unreliable and battery-dependent CMOS SRAM, played a very cruel joke with the UEFI developers, now NVRAM with every new version of the standard is gaining more and more crutches and props, and the end of this process is not visible. If you are interested in what they are trying to back up with a crutch, this article is for you.
By tradition, everyone who for some reason has not read the first three parts - I recommend starting with them, I look forward to the rest under the cut.

Part Four NVRAM

Minus one million idea

Honestly, I don’t know who exactly came up with the idea of ​​transferring the settings repository from CMOS SRAM, where it has been located for centuries, to the main chip, but at the moment it can be stated that this was still a bear service for iron producers and the developer firmware, and to end users. Apparently, Intel had some reasons for it, and therefore the interface to NVRAM, represented by the four Runtime services GetVariable / GetNextVariableName / QueryVariableInfo / SetVariable , became part of the very first published Intel (which before the organization of the UEFI Forum worked on it almost exclusively ) standard EFI 1.10, 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 (which are described below) and data stored in this variable.
By type, the variables are divided into ordinary ones (stored in RAM, they do not save values ​​when reloading), NV (stored in the SPI chip area allocated to them, read from there during reboot) and HR (stored in the SPI chip, but separately from NV, OS with UEFI support in order to inform the firmware about detected hardware errors).
By access level, the variables were initially divided into two types - BS (inaccessible after the start of OS loading) and RT(always available), but with the introduction of SecureBoot technology in the UEFI 2.3.1C standard, 2 more subspecies were added to the usual RT variables - AW (authentication is required for recording) and TA (the same thing, only with a time stamp 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 can be read and written both at boot time and from the OS. The standard also defines the rules for handling a variable, for example, the presence of the RT attribute automatically implies 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 ExitBS event that ends the UEFI bootloader) .
Everything would be fine if the interface described above were the only one, and only he would be used to access the variables. Unfortunately, this is not entirely true, and some NV variables almost bypass the NVRAM driver using the HII driver, which provides the user with the BIOS Setup menu, so the storage format of NV variables also had to be standardized, and now the NVRAM was stored not in the SPI chip, but somewhere it’s also quite difficult.
The most famous such variable of "dual access" - Setup, which stores almost 100% (with the exception of passwords and a couple of things) of the settings available for changing from the BIOS Setup. Its format is unique for almost every version and every system, but because the HII driver knows exactly what offset which setting is located, and this knowledge is quite easily extracted if there is a firmware image using a pair of open source utilities, this opens up some potentially dangerous opportunities for the attacker.

Attacks on NVRAM

Gentlemen forgetful 2

Because For storing NV variables, the SPI chip is used, for the operation of NVRAM, it is necessary to write to it during the operation of the OS, which immediately puts an end to protection with the help of an RO chip or PR-registers. Nevertheless, many system manufacturers still use PR registers, setting them up so that NVRAM falls into an area that is not write-protected, 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 attributes, including SecureBoot variables requiring authentication (which immediately makes the whole technology completely useless) and Setup (which sometimes allows you to disable the protection of the remaining parts of the firmware and after rebooting get already 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,
Another example of forgetfulness is to put RT for debugging on some important variable, such as Setup, and then forget to remove this attribute. The result - you can change the settings directly from the OS, it’s very convenient, only again the whole SecureBoot down the drain.

Over the edge

Another attack, old as the world and as simple as mooing - we write large variables, small variables, many variables, one and the same variable a hundred times in NVRAM, and so on and so forth, fluffy AFL to help you. Then we reboot and look at the reaction. The correct implementation of NVRAM will answer all unnecessary EFI_OUT_OF_RESOURCES requests with honor and after rebooting everything will work, but there are no examples and a different outcome, when NVRAM just collapses and the system rises, unable to continue loading. Most often, DoS is obtained from this, but if the attacker really wants to, very much, see above.

UEFI loader strikes back

This attack is also not very new, about it back in 2013 there was an excellent post comrade. Falseclock. The essence of the attack is that the loader (which you can use at least GRUB, at least UEFI Shell, at least any UEFI application) can execute arbitrary code before the ExitBS event occurs, i.e. The early stages of the bootloader have full access to BS variables, including Setup. If the platform manufacturer did not take care of prohibiting writing to this variable after the time window for invoking BIOS Setup ended (I saw such protection on exactly one industrial board, it is nowhere else), then the bootloader (or the user, if the bootloader has a shell ) can read and modify the contents of the Setup variable, for the fifth time I will not write about the danger of this. The proposed protection against such ugly bootloaders is SecureBoot,
In conclusion to the last part, I mentioned that the password for the BIOS 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. Using the appropriate utility for accessing NVRAM ( Read Universal ), the UEFI image parser ( UEFITool , PhoenixTool , uefi-firmware-parser ) and the IFR ( Universal IFR Extractor ) parser, you can organize access to all settings, including hidden ones, bypassing the password, and then also reset this same password when you get tired of digging through the “hole in the fence” in the BIOS Setup.

Socialist Remoters

Finally, the most innocuous NVRAM-related attacks, which can make your unsuspecting BIOS utility staffing Linux'ovaya efibootmgr. Depending on the phase of the moon and the intensity of cosmic rays, sometimes with the next update of the nucleus, it turns out not only to add the next variable BootXXXX, but also to delete several neighboring ones after that, and if the rays this time are especially high-energy - that's all. After that, about 30 percent of UEFI implementations by Phoenix or Insyde are completely stuck - after all, the BDS phase is over, and there is nothing more to boot from. At the same time, all the possibilities to get out of a stupor, like BIOS Setup, were also among those BootXXXX ones, and the user is forced to either use the Crisis Recovery subsystem (if he can in RTFM) or carry the system to a 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 mastery.

Best defense

It may sound paradoxical, but the best protection against all possible problems with NVRAM at once is removing NV from it, i.e. transferring all the variables lying on the SPI chip to RAM and setting write protection to the area with them using PR registers immediately after BIOS Setup (if you do before, the settings will no longer be saved). The only modern OS that somehow uses NVRAM recording is MacOS X, but they have their own lunapark without SMM and SecureBoot, so there is a separate discussion about them. Windows and Linux are great at experiencing the fact that NV + RT variables are no longer saved, installers can have problems (we write our bootloaders in BootXXXX, but they are not saved, sadness) and some very specific software (which has nosebleeds variables are needed, but I have never seen such software). Not the usual work with the OS, nor even updating the firmware (or its individual components) using the Capsule Update mechanism, an unsaved NVRAM has practically no effect. One wonders if it was needed from the very beginning ...

Conclusion

The cycle is gradually coming to an end, it remains to talk about a couple of historical attacks on SecureBoot, about the danger of unsigned Option ROMs, and about outstanding gentlemen (and ladies), thanks to which most of the described problems were discovered. Enough for a couple of parts.
Thank you readers for your attention, successful firmware, and remember - NVRAM needs to be protected from a young age.