About UEFI security, part five

After a short break, we continue to talk about UEFI security. This time it will be about SecureBoot technology, its advantages and disadvantages, about attacks on it and protection against them.

For the first time, SecureBoot was discussed in UEFI 2.2 in 2011, but finally all aspects were implemented in version 2.3.1C in early 2012. The main developer of the technology was Microsoft, which immediately stated that in order to obtain a Windows 8 Ready certificate for its not yet released new OS, implementation and inclusion of SecureBoot by default on all new PCs is required. This statement caused a wave of harsh criticism from supporters of free software, which successfully reached Habr .
If you are wondering exactly how the confrontation between MS and the community ended, how SecureBoot looks after almost 4 years of maturity, and what attacks against it are still possible - welcome to cat.

Stop, I almost forgot: in good tradition, a set of links to the previous parts , for those who managed to skip them.

Part Five. Secure boot

What is this anyway?

I do not think that after a dozen articles on Habré, it’s worth talking about SecureBoot in too much detail - this has already been done more than once without me. However, absolutely nothing to tell would be a crime against a reader unfamiliar with the topic, so we will go over the top, and we will send those who want to know everything and thoroughly familiar to the specification .
')
SecureBoot is a software technology with which UEFI-compatible firmware can verify the authenticity of external components executed by it (boot loaders, drivers, and UEFI OptionROMs). These executable components must be signed by an EDS that is checked during the download and in case of its complete absence, damage, absence in the trusted list ( db ) or presence in the prohibited list ( dbx ), the corresponding component does not start (sometimes this behavior is configured, which also can play a cruel joke, but more on that later). As a digital signature algorithm, the standard currently recommends a combination of RSA2048 and SHA256, which are used on almost all the systems I've seen in a live system.

A bit about the keys

SecureBoot uses the following key hierarchy:



At the top is PK — the master key that establishes a trust relationship between the user of the platform and its firmware. It, like any RSA key, consists of the PKpub public key and the PKpriv private key and is stored in NVRAM in the form of a self-signed certificate. The owner of the closed part of the PKpriv is not without reason called the owner of the platform .

Depending on the level of security required, a PK can be generated as follows:

• Own key for each individual PC. Maximum security, it’s also the maximum hemorrhoids with key management, but leaks are practically not terrible, and the compromise of the system with the leaked key does not lead to the compromise of the neighboring one.
• Common key for each model mat. fees. Less safe, but easier to maintain, especially if the car park is assembled on the same boards.
• Common key of each ruler mat. boards The same as in the previous paragraph, a little less security at the price of a bit more convenience, the classic case of security-convenience trade-off.
• Common key for all motherboards manufacturer. The most ridiculous in terms of security, but at the same time, unfortunately, almost the most popular solution. The key is stored directly in the source tree and flows away with them, after which no SecureBoot on the boards of this manufacturer is already a hindrance. At the same time, the source codes most often flow away quietly, and the manufacturer may produce obviously vulnerable products for another couple of years.

Initially, PK is generated by the platform vendor, and is not involved in signing and verifying the signatures of executable components, but is used to manage the KEK key store. The owner of KEKpriv specification calls the authorized user . Each KEK key establishes a trust relationship between the manufacturer of the executable component and the firmware. These keys are used to manage db repositories (where certificates and hashes of components allowed to run are located), and dbx (where a KEKpriv holder can add certificates and components hashes that should not be allowed to start up despite the correct signature).

Who is the first in kings?

In most SecureBoot configurations, PK is supplied by the manufacturer mat by default. boards, KEK is the only Microsoft Corporation KEK CA 2011 certificate, and db always has a Microsoft Windows Production CA 2011 certificate, but sometimes it is accompanied by a Canonical certificate and a certificate of the platform manufacturer, which have signed all sorts of utilities for updating the firmware and that's it. The dbx storage on most systems is empty, but not so long ago, MS made several entries in it and now require them on new systems to obtain a Windows 10 Ready certificate. It turns out that in terms of SecureBoot in the default configuration, your system is owned by the manufacturer mate. boards, and its only authorized user is Microsoft. Fortunately (and for the most part due to the pressure of the ACT community), this sad picture on the vast majority of systems for x86 can be destroyed by removing the standard keys and adding my own from the BIOS Setup, but I plan to write about it separately.

CSM incompatibility

It remains to mention that SecureBoot is not compatible and should not be included with CSM , i.e. if you are still using old OSes that cannot boot without CSM, then you will not be of any use from SecureBoot. The most interesting thing is that MS still does not want to add GOP support to Windows 7, and without it, booting this OS without CSM either doesn’t work at all or goes blind, which almost certainly makes Windows 7 incompatible with SecureBoot, even if the user is on his own will sign the bootloader for her. The share of Windows 7 in the corporate segment is much higher than the share of newer operating systems, and therefore systems with SecureBoot enabled are still not very popular where it really would be useful.

SecureBoot attacks

About vectors

First you need to understand exactly what parts of SecureBoot can be attacked and what threatens a successful attack:

• NVRAM. Since both PK, KEK, db and dbx, and other SecureBoot-related variables are stored in NVRAM, a successful attack on it most often leads to the disabling or compromising of SecureBoot.
• Implementation. If everything is fine with NVRAM, problems may be in the implementation of signature verification, key storage, etc.
• The keys. The attack is both complex and simple. All you need to do is steal the private key from someone in the chain of trust and sign your malicious loader with it.
• Trusted bootloader. Even easier than the previous item, especially for holders of a Canonical certificate in db. Just change the current bootloader to the signed GRUB2 certificate from the Ubuntu repositories, which in turn will download anything of any degree of harmfulness.

Actually attacks

Disabling SecureBoot by removing PK

If an attacker has write access to the NVRAM storage, which is often the case for those who like to protect the SPI chip with just a couple of PR registers, then the current PK can be trivially deleted, which will automatically disable SecureBoot, putting it into new key installation mode.

Disable SecureBoot by editing CurrentMode

This attack is a combination of an attack on NVRAM and implementation. On some systems, the current SecureBoot mode is controlled by writing to the Setup variable, and if it unexpectedly has the RT flag for everyone, then the attacker can disable SecureBoot by simply writing zero at the desired offset in Setup, which in turn can be easily found by analyzing the IFR dump. The attack is dull as a boot, but there are still a lot of systems that are susceptible to it.

Bypassing SecureBoot ExecutionPolicy

The variation of the previous attack, but this time is disabled not by SecureBoot itself, but by the prohibition to continue the download if the digital signature does not match or is missing. It also requires the RT flag on the Setup variable and is slightly less common than the previous version, but it allows you to bypass SecureBoot silently without turning it off.

SecureBoot Bypass NVRAM Damage

On some systems, to bypass SecureBoot, it is enough to spoil NVRAM a little (for example, by filling the vault out of place) to disable or bypass SecureBoot. Such behavior is rare, but the attack is so simple that it makes sense to try it on any system. As a last resort, instead of bypassing SecureBoot, you may end up with a DoS if the NVRAM driver is completely bad.

SecureBoot bypass using a PCI (e) device

Theoretically, launching UEFI OptionROMs from PCI devices with SecureBoot enabled should not occur if the corresponding OROM did not pass verification, but in practice a huge number of systems trust PCI devices unconditionally and start everything from there without any checks. There are many examples of this behavior, and any systems without SecureBoot are automatically affected by this attack , which is why PCI (e) takeaway to external connectors, like Thunderbolt, Firewire, PCMCIA, ExpressCard, etc. - a crime against the security of the platform, even without taking into account the fact that any PCI device can initiate DMA with any region of physical memory except SMRAM (and only if the platform manufacturer did not forget to install protection) and drag off all the secrets of the OS and user.

Bypassing SecureBoot by converting the loader from PE to TE

The old implementation attack, which suddenly turned out to be a good half of the implementations (due to the fact that almost all IBVs use the reference implementation from TianoCore). The essence of the attack: The UEFI loader and, in general, any executable UEFI file can be either in PE format or in TE format (which, in fact, the same PE, only with truncated headers, so that cache space is less). The TE format is very rarely used for some firmware components other than PEI modules (since only in the first half of PEI, prior to RAM initialization, it makes sense to save 240h bytes on the header), and therefore the reference implementation of the EDS check did not check it images in the TE format in general, and due to a combination of two small errors, the verification of such an image always ended in success. PE -> TE conversion is trivial, and SecureBoot could be bypassed with only a small change in the file with the loader, so the problem was recognized as serious and quickly fixed. Nevertheless, there are still a lot of old systems with this problem, and therefore they still remember about this attack.

Bypassing SecureBoot from external media

This is not even an attack, but rather a misunderstanding of some users that SecureBoot does not protect against loader substitution, and the physically present attacker can boot the system from its media. Sometimes they try to protect themselves from this with a password on the BIOS and the boot device selection menu, but good developers from MS allow you to select it from Windows, for which you just hold down the Shift and select the "reboot" action on the login screen, and then choose from the menu that appears boot device. To dear comrades from MS - my many thanks.

Conclusion

Well, with SecureBoot, somehow, we figured out the next (hopefully the final) part, we’ll talk about software and personalities.
Thank you for your attention, secure SecureBoot.