>In a normal WinRE session, you have a X:\Windows\System32 directory that has a winpeshl.ini file in it

>However, with the YellowKey exploit, it looks like Transactional NTFS bits on a USB Drive are able to delete the winpeshl.ini file on ANOTHER DRIVE

Interesting. I dont know about this environment - some kind of naive file handle contructing/passing? But then, why require a key press during winre reboot?

I wonder how patachable this is. The thousands of winre thumb drives are certainly out of reach; maybe the bitlocker side update the access permissions? Would it require unenc/reenc?

Seems like lots more to follow

▲

gruez 3 hours ago | parent [-]

>The thousands of winre thumb drives are certainly out of reach; maybe the bitlocker side update the access permissions? Would it require unenc/reenc?

The part that isn't mentioned is that the win re is privileged because windows stores a decryption key in the TPM that allows win re to decrypt the disk even without the recovery key. That's why the attack requires win re in the first place, rather than booting into an ubuntu live cd or whatever. This also means you don't have to patch all the winRE thumbdrives out there because their secureboot signatures can simply be revoked, meaning they can't pass TPM validation anymore, therefore they won't be able to decrypt any disks.

	▲	bri3d an hour ago \| parent \| next [-]
		> This also means you don't have to patch all the winRE thumbdrives out there because their secureboot signatures can simply be revoked, meaning they can't pass TPM validation anymore, therefore they won't be able to decrypt any disks. WinRE runs internally, not from a thumb drive, which is why the bootloader will unseal the disk for it (just like if you have a systemd recovery set up on a Linux distribution). It doesn't have a separate key or anything, it's just allowed to use the "main" one, by design. Microsoft just need to patch the WinRE partition in a normal Windows Update to fix the NTFS transaction log driver; no Secure Boot revocation or TPM-related changes are necessary (which is good for them, because _that_ would be a disaster). By and large this whole thing is orthogonal to BitLocker overall; boot-time unsealed BitLocker is vulnerable to any post-bootloader auth bypass by design, and this is a goofy post-bootloader auth bypass bug.
	▲	steve1977 2 hours ago \| parent \| prev [-]
		Then I guess it is fair to call this a backdoor indeed.