Event details
Three questions related to Secure Boot:
- When updating Secure Boot variables (like this db update but also on some older dbx updates), some older firmware has problems due to maximum variable size or size of variable store. UEFI exposes this information via RT:QueryVariableInfo, and when booting Linux, you can see by querying free space of efivarfs. Is there a way from Windows userspace (e.g. Powershell or a NTDLL exported function) to get this information? Max variable length, max variable store, remaining variable store.
- When applying the hardening measures for Black Lotus and adding SVN values to dbx, some older versions of bootmgfw.efi deny booting due to SVN mismatch. This is by design. BUT: When you boot from some recovery media that comes with its own loader that sets its own security protocol file authentication callback (like shim does), to use a fixed set of hashes, and bypasses DBX that way, and chainload this (whitelisted) bootmgfw.efi, the SVN values are still checked in DBX and deny booting. Is this by design? If yes, what is the preferred way to set up such media? Try to remove the signature from bootmgfw and patch the check out? Or use an old version of bootmgfw that does not check SVN yet (like one from 2017 I found on an old Win10 install disk)? Always having the latest bootmgfw on these media is not an option for us, and we'd like to apply the SVN hardenings for "normal" boots (not via this recovery media) if possible.
- The current certificate update will install the replacements for the Third Party EFI CA to DB only if the old Third Party EFI CA is included in DB. However, as Microsoft published signed variable updates for adding them to DB on every system that has the old KEK, nothing prevents an adversary from doing so. Is this taken into account when evaluating security implications of adding anything to DBX which is signed by these keys (nothing revoked yet, but in the future?). E.g. by applying these DBX updates when old KEK is in DB, even when new Third party EFI CA replacements are not there? Or by adding those replacements to DBX at a later stage if not present in DB?
I am aware you probably cannot answer them by heart, therefore I'll give you a week advance notice :)
MicrosoftHi Mihi, I noticed that you have been very active answering questions. Thank you for all of your efforts.
Hi Mihi, I’ve noticed how active you’ve been in answering questions. Thank you for all your efforts — it’s been very helpful.
- I don't know of a way to do this in Windows. As far as I know it's not possible.
- As far as I know, there isn’t a way to do this in Windows. The boot managers that enforce the Secure Version Number (SVN) are designed to avoid running if they don’t meet the minimum SVN defined in the DBX. Blocking older boot managers, whether they’re on the internal disk or on external media, is intentional because it prevents rollback attacks. Unfortunately, this also affects some external bootable media scenarios.
You’ll see a new Get‑SecureBootSVN PowerShell command coming in March that should make it easier to check the SVN on a device. - Yes, it is possible to add the new third‑party certificates to the DB if you have administrative or physical access. For devices where this is a concern, we recommend using BitLocker with a PCR7 and PCR11 binding policy. PCR7 measures the Secure Boot state, so adding third‑party certificates to firmware would change the PCR7 measurement and trigger BitLocker recovery.
Thanks again for all your help in the discussion threads — it’s very much appreciated.
Arden
Hello Arden,
thank you for the feedback.
About the answer to the third question:
- To protect against physical access, BitLocker will certainly help. But I don't think it matters whether it binds against PCR7 or PCR4 (among others). As the boot binary signed by Third-Party CA will certainly not be identical to the one used by Microsoft
- To protect against malware having administrator/SYSTEM access, Bitlocker won't help. Attacker can just suspend (or disable) bitlocker before carring on with their attack.
- Arden_White
You’ve been bringing a lot of great points to these discussions, and I appreciate the work you’ve been putting in. It is making a real difference.
You are right. BitLocker will not protect against an attacker who already has administrative access, since BitLocker is designed to protect data at rest - meaning when the device is powered off.
PCR4 has a disadvantage in that some devices will run small firmware applications under certain conditions, and those executions are measured into PCR4. That can lead to unexpected measurement changes. For example, we have seen this when a battery is low and a firmware power application starts running. The device will then go into BitLocker recovery.
PCR7 behaves differently. It protects against Secure Boot configuration changes, and it can help protect against a boot manager swap if the replacement boot manager is signed by a different publisher than the original. I am doing this from memory, but that is the general behavior.
Thanks again