From db4bd6f319bcabb527f57e965b53e5cb7a874e90 Mon Sep 17 00:00:00 2001 From: Rairii <2650838+Wack0@users.noreply.github.com> Date: Sat, 9 Aug 2025 21:09:36 +0100 Subject: [PATCH] add CVE-2025-48804 --- readme.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/readme.md b/readme.md index f549879..8e2db78 100644 --- a/readme.md +++ b/readme.md @@ -40,6 +40,8 @@ Where code execution can be obtained inside a boot application, it may be possib | CrashXTS: cryptographic attack, allows for precise corruption of SYSTEM hive leading to hiberfile written in the clear | BitLocker uses AES-XTS. By taking several images of the crypted partition, it is possible to find the offset of the `SYSTEM` hive, and therefore the offset of `SYSTEM\ControlSet001\Control\CrashControl` key, and corrupt the hive in such a way that the filter driver used for encrypting the hiberfile when writing it out to disk is not loaded. Therefore, one can then hibernate the system, dump the partition again, and get a full plaintext (compressed) RAM dump including the volume keys.

See also [the public writeup](https://dfir.ru/2025/01/20/cve-2025-21210-aka-crashxts-a-practical-randomization-attack-against-bitlocker/).

Fixed by causing a bugcheck if that filter driver is not present for loading when it is required. This bug is CVE-2025-21210. | January 2025 | January 2025 | Maxim Suhanov | | break out in hives: systemdatadevice element causes winload to use attacker specified SYSTEM hive | Starting from Windows 10 (th1), support for the `systemdatadevice` element was added to winload. If present, winload reads the SYSTEM hive from this device instead of osdevice.

Thus, attacker can grab SYSTEM hive from WinPE, modify Setup!CmdLine to cmd.exe, and cause winload to use this hive when booting WinRE.

When booting WinRE after this, a SYSTEM shell will open with the bitlocker keys in memory for osvolume if they were derived; thus, bitlocker bypass.

Fixed by removing the ability to load SYSTEM hive from systemdatadevice. This bug is CVE-2024-20666. | January 2024 (winre image must be patched manually) | February 2025; discovered in March 2023 | Rairii | | break out in hives 2: alternative method for exploiting systemdatadevice element, usable with a downgrade attack | The fix for break out in hives updated winload.

However, earlier (unfixed) revisions of winload can **potentially** still run to boot its major version of Windows (may not work in practise for every version).

Thus, attacker can bring in an old winload, modify BCD to boot from it, and repeat the attack, however a different exploitation method must be used.

**The `winpe` element must be set in BCD (if it is not, the SYSTEM hive in the bitlocker encrypted osvolume will get corrupted!)**

The working SYSTEM hive here would come from an `install.wim` image of the same major version of Windows (not WinPE/WinRE). The Win32 subsystem will not be able to initialise fully, but smss can be configured in `ControlSet001\Control\Session Manager!SetupExecute` to achieve arbitrary native subsystem code execution as SYSTEM with derived keys in memory.

Fixed by wiping `systemdatadevice` element in bootmgr if Secure Boot is enabled, but the fix was only applied to the PCA 2023-signed bootmgr_ex, so **without the KB5025885 mitigation enabled, this vulnerability is still present and remains unfixed.** This bug is CVE-2025-21213. | January 2025, in PCA2023-signed bootmgr_ex only | February 2025; discovered in January 2024 (after the original fix) | Rairii | +| Boot environment does not check SDI when loading ramdisk, which has offset to the used WIM | When loading a ramdisk, the boot environment (and NT `wimfsf.sys`) gets the offset to the used WIM from the SDI file if it's present, and there is no validation of the SDI file used. Therefore a crafted SDI file can be used in the recovery sequence to boot an arbitrary WinPE WIM with the osdevice bitlocker keys derived.

Fixed by checking that the calculated WIM offset is equal to the actual load offset of the WIM, and returning STATUS_INVALID_IMAGE_FORMAT if not. This bug is CVE-2025-48804. | July 2025 | August 2025 (at Black Hat) | Alon Leviev and Netanel Ben Simon of Microsoft (MORSE) | + ### dangerous association