How is hibernation supported, on machines with UEFI Secure Boot?

Question

I've been learning about UEFI Secure Boot, which attempts to prevent "bootkits" by locking down the boot process so that only signed bootloaders and kernels can be loaded.

Hibernation seems like a major attack vector. Hibernation (also known as suspend-to-disk) involves writing the entire state of memory, including all of kernel memory, to disk. After this state is written to disk, you can shut off power. When power is restored, you resume by reading this state from disk and writing it into memory. What prevents an attacker from modifying the hibernated state of memory on disk, e.g., modifying kernel memory to inject malware into the kernel? When the user resumes, it seems like this will load into memory a now-infected OS kernel.

Similarly, evil malware could presumably create a crafted hibernation file (containing a modified version of a real hibernation file, modified to insert malware into the running kernel) and then force a reboot. Upon reboot I presume this will load the hibernated image into memory -- which would seem to violate the security goals of UEFI Secure Boot.

I suspect I've gotten myself confused or twisted up somehow. Can anyone clear this up? Is hibernation compatible with UEFI Secure Boot? Does it pose any security risks to the goals of UEFI Secure Boot, and if so, how are these risks being addressed in deployed uses of UEFI Secure Boot?

Answer 1

Is hibernation compatible with UEFI Secure Boot?

For that you need to look at section 27 of the UEFI spec. In this specification, you will see a full explanation of the protocols in use. I'll briefly summarise them - this is a rough interpretation and might have loose edges (if you want a definitive interpreration, find one of the UEFI people :) ):

• The EFI_AUTHENTICATION_INFO_PROTOCOL section defines a number of methods for getting and setting authentication information for a number of different implementations.
• Signing UEFI drivers (support applications for the UEFI firmware). Since UEFI executables are based on the Windows PE image file format, you can think of this as comparable to authenticode for EFI modules.
• EFI_HASH_PROTOCOL provides the programming API for hashing.

• Then the juicy parts: firmware/OS key exchange. This is responsible for enrolling the platform key. EFI refers to two modes:

  • Setup mode
  • User mode The former mode refers to a setup without an enrolled key, the latter to one with an enrolled key.

  The enrolled key is the private key root from which image signatures will be trusted.

• passing public keys to the OS firmware section is exactly what it sounds like - a protocol for notifying the firmware of a key it should use to talk to the operating system.
• UEFI Image Validation refers to the process of checking a UEFI Image (bootloader etc) against a signature database.
• The signature database is a list of valid UEFI images which have been signed with the platform key. An image must match a signature in the signature database to boot.

There is a reason for covering these EFI spec details is to point out that the UEFI Secure Boot spec covers to what extent UEFI secure boot extends - that is, it aims to achieve two things:

• The UEFI Loader will only load EFI Images whose signatures are present in the signature database if UEFI secure boot is enabled and a platform key is enrolled (this is done by the platform owner).
• The UEFI spec provides a means to communicate information between the operating system and the UEFI firmware to interrogate the signature database and EFI variables.

The important point here is that there is no requirement for an EFI Image, once loaded, or an OS Kernel once loaded to enforce signing on anything it subsequently loads.

For example;

• Fedora will enforce signing all the way down for the kernel and respective modules - see this status update and this
• Have a read of this article on the UEFI shim that came out of the Fedora EFI boot process. This shim can optionally have a UEFI variable set to disable signing checks on later parts of the boot process - like the kernel. In more detail

• Ubuntu itself will not be signing its kernels:

  Therefore, we will only be requiring authentication of boot loader binaries. Ubuntu will not require signed kernel images or kernel modules.

So, ok, let's get back to UEFI:

Similarly, evil malware could presumably create a crafted hibernation file (containing a modified version of a real hibernation file, modified to insert malware into the running kernel) and then force a reboot. Upon reboot I presume this will load the hibernated image into memory -- which would seem to violate the security goals of UEFI Secure Boot.

Yes. This is a perfectly good attack vector for current operating systems and has its origins in the pagefile attack.

Both of these attacks work because the kernel (used to, in the case of the Windows kernel) blindly loaded data from disk back into RAM. Correct modification lets you alter drivers, install your own etc and off you go, ring 0 and one compromised system.

In a UEFI secure boot environment, the EFI firmware guarantees that your bootloader will not have been tampered with up to the point of shutting down the EFI firmware and proceeding to the operating system. That's about it. UEFI secure boot doesn't guarantee the loaded operating system is unmodified, or that the loaded operating system has loaded altered images from boot. That is up to the operating system to check and enforce.

Now some personal thoughts:

Does it pose any security risks to the goals of UEFI Secure Boot

I suppose it does, in the sense that what you expect from UEFI Secure Boot is a sane state kernel. That's not what you're guaranteed to get, but it's what you expect.

how are these risks being addressed in deployed uses of UEFI Secure Boot?

I think more accurately these risks are being mitigated across the board by code signing initiatives such as AuthentiCode. 64-bit Windows, for example, will not load unsigned driver code unless you perform a special dance involving F8 and boot menus. Most Microsoft images are signed and - I don't know but would guess - ntkrnlmp.exe is signed and validated by the Microsoft EFI bootloader.

As you can see, distributions such as Fedora have certainly adopted this approach as security of the system as a whole means little if you have simply got a verified bootloader.

The next stage of this process I suspect is to close attack vectors such as hibernate. For example, the page file attack was fixed by Microsoft. It is trivial to fix if you consider that you simply need a signed checksum which you can produce using, for example, one of the keys stored in the EFI firmware and verify in boot, either in the bootloader or the kernel.

Answer 2

Vulnerable But Addressable

As user2213 indicated, hibernation file attacks are not prevented by anything in the UEFI Secure Boot specification.

The solution is to use full-disk encryption on the system volume and any volumes containing paged/hibernation data. Windows has Bitlocker, and Linux has LUKS.

On a typical Windows installation, you only need to encrypt C:\ to prevent this attack, as hiberfil.sys is stored there by default.

Due to the low overhead for performing AES on modern CPUs, it is probably a good idea to encrypt all drives. Intel CPUs have supported hardware acceleration of AES for about a decade.

Answer 3

Actually, all an OS needs to do is simply validate that the memory image has not been updated. This can be verified by having the OS boot loader hash the on-disk image as it is loaded. As long as the hash is stored somewhere safe and the image is validated from inside the firmware-validated boot loader, everything is safe.