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 :) ):
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.
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.