diff --git a/readme.md b/readme.md index 8e2db78..264e214 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 | NTFS transaction logs 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 | ### dangerous association