From b553a1c6a3c78c23fad450f5287808a844e2d025 Mon Sep 17 00:00:00 2001
From: zc <2650838+Wack0@users.noreply.github.com>
Date: Tue, 2 May 2023 16:36:57 +0100
Subject: [PATCH] add more details about CVE-2022-29127, the MSRC page now
gives credits
---
readme.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/readme.md b/readme.md
index d79eee7..3637cb2 100644
--- a/readme.md
+++ b/readme.md
@@ -32,7 +32,7 @@ Where code execution can be obtained inside a boot application, it may be possib
| Summary | Description | Fixed | Public disclosure timeframe | Discovered by |
| --- | --- | --- | --- | --- |
| Boot environment does not wipe previous keytable when creating a new one | The boot library initialisation function has a set of flags passed to it.
If bit 7 is set (which is the case for at least bootmgr), any existing key table is ignored, and a new one created.
The existing key table is not wiped, and remains in memory.
This allows for an attacker to load bootmgr with arbitrary `osdevice`, then either exploit bootmgr to get code execution, or use RS2+ bootmgr (to ensure only one Secure Boot Policy is present) to load WinPE and use a known vulnerable driver, to find and dump the keytable.
The use of legacy integrity validation prevents this attack from working, due to the boot application allowlist in BitLocker partition metadata. | Mitigated in January 2022 (by preventing loading bootmgr in most cases).
Fixed in March 2023 with build 25330 (existing keytable will be mapped and wiped before creating a new one).
**A downgrade attack would still work to exploit this vulnerability.** | August 2022 (with baton drop); discovered in January 2022. | Rairii |
-| Legacy integrity validation implemented associated options incorrectly | **Legacy integrity validation affected (where vulnerable bootmgr is used), secure boot integrity validation not affected at all**
BitLocker legacy integrity validation walks through all boot options, and either ensures they exist, ensures any unknown options do NOT exist, or ensures they are unchanged by hashing them.
The original implementation attempted to also walk through associated options, but used the incorrect offset to do so.
This would allow for crafting a BCD that contained boot options invisible to BitLocker legacy integrity validation.
Many dangerous options here, in particular `debug`, can lead to BitLocker key table dumping.
Fixed by using the correct offset when walking through associated options. This bug is CVE-2022-29127. | May 2022 | June 2022 (at emfcamp) | Unknown |
+| Legacy integrity validation implemented associated options incorrectly | **Legacy integrity validation affected (where vulnerable bootmgr is used), secure boot integrity validation not affected at all**
BitLocker legacy integrity validation walks through all boot options, and either ensures they exist, ensures any unknown options do NOT exist, or ensures they are unchanged by hashing them.
The original implementation attempted to also walk through associated options, but used the incorrect offset to do so.
This would allow for crafting a BCD that contained boot options invisible to BitLocker legacy integrity validation.
Many dangerous options here, in particular `debug`, can lead to BitLocker key table dumping.
Fixed by using the correct offset when walking through associated options. This bug is CVE-2022-29127. | May 2022 | June 2022 (at emfcamp, thanks to bindiffing) | Matt Wesemann of Microsoft (WDG) |
| [dangerous association](#dangerous-association): Legacy integrity validation implemented associated options incorrectly (part 2) | **Legacy integrity validation affected (where vulnerable bootmgr is used), secure boot integrity validation not affected at all**
The fix for the previous vuln was incorrect and only checked one level of associated options, whereas code that used the boot options would recurse.
This would allow for crafting a BCD that contained boot options invisible to BitLocker legacy integrity validation.
See also [the public disclosure](https://haqueers.com/@Rairii/109439636170607042).
Fixed by recursing into associated options like other code does. This bug is CVE-2022-22048. | July 2022 | December 2022; discovered in May 2022 when bindiffing previous patch | Rairii |
| [bitpixie](#bitpixie): PXE soft reboot does not wipe derived bitlocker keys from memory | **Only exploitable on UEFI systems (not legacy BIOS, or CSM). Legacy integrity validation affected (where vulnerable bootmgr is used), secure boot integrity validation affected**
PXE soft reboot is allowed when booting from network, and just does `BS->LoadImage()` and `BS->StartImage()`.
Derived BitLocker keys are still in memory at the time `BS->StartImage` is called.
They can then be dumped from memory.
In addition: BitLocker keys are derived very early into loading a boot application. If loading the PE from disk failed, integrity validation is not performed and derived keys remain in memory.
A PXE soft reboot can then be performed, thus this bypasses legacy integrity validation too.
See also [the public disclosure](https://haqueers.com/@Rairii/109817927668949732).
Fixed by wiping bitlocker keytables in `bootmgr!BlNetSoftReboot` before calling `bootmgr!PxeSoftReboot`. This bug is CVE-2023-21563. | November 2022 (build 25236); January 2023 (backport)
Where Secure Boot integrity validation is used, **a downgrade attack would still work to exploit this vulnerability.** | February 2023, discovered in August 2022 | Rairii |