[ad_1]
Last week, I posted about UEFI Secure Boot, showing how to look at the Secure Boot “db” on a UEFI device. To summarize, the certificates in the UEFI “db” variable are used by the UEFI firmware to determine if the current boot program (e.g. bootmgr.efi) is allowed to run on the device. But there is more to the story than that.
To look at the bigger picture, there are four UEFI variables that are used:
- db, the “signature database.” Entries here (typically certificates) determine what EFI executables are allowed to run on the device. So this is an “allow” list.
- dbx, the “forbidden signatures database.” Entries here are typically SHA256 hashes of specific UEFI binaries, i.e. those things that were signed by a certificate in the “db” list but later found to be bad (e.g. having a security vulnerability that compromises the firmware). So this is a “block” list.
- kek, the “key exchange key.” This specifies who is able to update the signature database (the “db” and “dbx” keys). Interestingly, any UEFI binaries signed by the “kek” key can also boot on the device.
- pk, the “platform key.” The “pk” variable contains a single certificate that controls access to the “kek” and “db” variables. If this value is cleared, it effectively turns off Secure Boot (putting the device in setup mode).
So the overall rules are a little more complex. UEFI will allow a UEFI binary to execute if:
- It is signed by a key in the “db”, or explicitly has its hash in the “db” (so you can allow a single binary if you want).
- It is signed by a key in the “kek” (which seems to be uncommon).
- Its hash isn’t in the “dbx” list.
To help visualize that, I updated the UEFIv2 module so that it can show all of those variables. Here’s the view from my workstation, first of the “db” (which we saw in the last blog):
Now, when we look at the “dbx”, we can see a bunch of forbidden signatures, where each one specifies a single UEFI binary that is blocked:
The “kek” shows that Microsoft (or really, anything signed by Microsoft with that key) can update the signature database (“db” and “dbx”):
The “pk” shows that a Lenovo certificate controls access to the other variables (so the firmware setup screens can use that to do things like turn off Secure Boot):
So generally, this is a fairly static setup — except for “dbx.” To explore that a little, let’s look at a specific scenario, starting with this announced security vulnerability, CVE-2020-0689:
“A security feature bypass vulnerability exists in secure boot, aka ‘Microsoft Secure Boot Security Feature Bypass Vulnerability’.”
Yes, that’s a vague description, but bypassing Secure Boot kind of defeats the purpose of Secure Boot, so it’s important to address that. The Microsoft security bulletin goes into a little more detail:
“A security feature bypass vulnerability exists in secure boot. An attacker who successfully exploited the vulnerability can bypass secure boot and load untrusted software. To exploit the vulnerability, an attacker could run a specially crafted application. The security update addresses the vulnerability by blocking vulnerable third-party bootloaders.”
Alright, so it would make sense then to block these vulnerable third-party bootloaders by adding entries to the “dbx” for them. So you will see a link in the Microsoft bulletin that points to an update that does exactly that. (Definitely read through the notes in that article for details around BitLocker complications; if you don’t deploy the update correctly, the device could go into BitLocker recovery.) If you look at the update, it contains a “Dbxupdate.bin” file containing the list of SHA256 hashes that need to be added. So, as long as you’ve deployed this update, you’re good to go.
Had enough of UEFI Secure Boot yet? There is one additional twist. While there are Linux distributions that support Secure Boot (using modules signed using the Microsoft UEFI certificate for third-party binaries), there is also a “shim” setup that can be used to load OS distributions that haven’t been signed by Microsoft. You can read the details in this article and this article. Basically, it adds another UEFI variable for “machine owner keys.” That lets you keep Secure Boot on, using a “shim.efi” boot loader that is signed by the Microsoft UEFI certificate. That “shim” bootloader can then allow other binaries to load by checking to see if they are signed by one of these “machine owner keys.”
All in the name of keeping your firmware secure, and you in control. (Of course if you don’t secure the firmware settings, someone with physical access to the device can defeat all of this…)
[ad_2]Source link
