diff --git a/readme.md b/readme.md index e339b74..90a37f0 100644 --- a/readme.md +++ b/readme.md @@ -41,7 +41,7 @@ Where code execution can be obtained inside a boot application, it may be possib | 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) | -| [YellowKey](https://github.com/Nightmare-Eclipse/YellowKey) aka trans writes: Filesystem transaction files located on one volume can affect files on another volume | Germanium introduced a new filesystem transaction feature (unrelated to NTFS transactions). Logs for this are on disk and parsed by `fstx.dll` (part of the servicing stack), and in WinPE only it is loaded by new native executable `autofstx.exe` ("Boot-time FsTx Update Recovery Utility" - "This utility recovers failed FsTx updates at boot-time.") which smss runs due to registry entry.

These logs contain full NT paths, and thus can affect files on another volume.

This can be used when booting WinRE with a removable drive attached (NTFS formatted) to delete `winpeshl.ini` on the ramdisk. With this file deleted, `winpeshl.exe` will launch a SYSTEM shell if Ctrl key is held, with the derived osdevice bitlocker keys in memory.

See also [additional writeup by Will Dormann](https://infosec.exchange/@wdormann/116565129854382214). | None | May 2026 | Nightmare-Eclipse | +| [YellowKey](https://github.com/Nightmare-Eclipse/YellowKey) aka trans writes: Filesystem transaction files located on one volume can affect files on another volume | Germanium introduced a new filesystem transaction feature (unrelated to NTFS transactions). Logs for this are on disk and parsed by `fstx.dll` (part of the servicing stack), and in WinPE only it is loaded by new native executable `autofstx.exe` ("Boot-time FsTx Update Recovery Utility" - "This utility recovers failed FsTx updates at boot-time.") which smss runs due to registry entry.

These logs contain full NT paths, and thus can affect files on another volume.

This can be used when booting WinRE with a removable drive attached (NTFS formatted) to delete `winpeshl.ini` on the ramdisk. With this file deleted, `winpeshl.exe` will launch a SYSTEM shell if Ctrl key is held, with the derived osdevice bitlocker keys in memory.

See also [additional writeup by Will Dormann](https://infosec.exchange/@wdormann/116565129854382214). This bug is CVE-2026-45585. | None | May 2026 | Nightmare-Eclipse | | [ram leak](#ram-leak): Boot environment has no restrictions on ramdisk creation device | When configured to create a ramdisk, the file to load and device to load it from is provided in the BCD.

The boot environment has no checks on the device passed, and thus, BitLocker-encrypted partitions are allowed, assuming the keys can be derived.

Therefore, an attacker can set up a ramdisk with an arbitrary file from a BitLocker-encrypted partition, and the file contents will stay in RAM even if the derived BitLocker keys are wiped, and can be dumped later.

Additionally, an attacker can use this to determine whether a file exists on a BitLocker-encrypted OS partition.

Interesting targets include: hibernation file (contains derived bitlocker keys, and is compressed so should fit entirely into RAM, especially if "shutting down" aka logoff-then-hibernate from the logon screen), pagefile, SYSTEM and SAM hives, any third-party service or driver (identified from SYSTEM hive) to check for vulnerabilities. | None. MSRC closed as low priority due to misunderstanding. | May 2026, originally discovered March 2025. | Rairii | ### dangerous association