IMPORTANT Issue to be aware of if you use BitLocker on your OS drive

Compared to a setup stick, bootable, you don't have anything more with winre active. Setup includes all that in winre in it's repair options "repair my computer". Having winre is just good for those unable to obtain or boot a stick.

Sure, we lose something with it since we leave the default configuration, but for good reasons.
Ok, now this shouldn't go on forever :-/ good-bye for now.

Good discussion. However, there is still a couple of very important details that eludes me:

1) Why does this issue affect only people who boot the recovery environment from the HD and not from other media such a flash drive?

2) What happens if someone does replace the winre.wim with an older version?

I may go on an expedition to try to find some answers to these questions. If anyone has already done so, I would love to hear your findings.

1) It could be that it makes a difference whether the machine is rebooted from a (windows is) running state (which means, the encryption key is in RAM at reboot time). Possibly, that key is not / not correctly overwritten when the machine reboots into WinRE and although WinRE asks for the recovery key, which suggests, the drive is inaccessible, one can somehow still work (=unlock c:) with what's in RAM. That's speculation and can only be falsified by analyzing RAM or by waiting for MS to disclose details.

2) As said, I tried that and well, the machine happily eats the old version and boots into the old version without BL recovery being triggered at any point in time, although all PCRs banks where activated by me at encryption time. So if you use DISM to analyse the overwritten WinRE.wim it will of course not see nor utilize the patch you had applied to the overwritten one.
Or what did you mean to ask?

Without any further guidance by MS, this will be speculation and need reverse engineering. So I stay careful and disable WinRE since none of my clients in the last 15 years (since it was introduced) ever truly needed it before (ymmv), because all it does can be achieved from a setup boot stick.

New script on Github developed by Microsoft to help automate patching - GitHub - takondo/WinREupdate: Sample script to patch WinRE

"This is a sample PowerShell script developed by the Microsoft product team to help automate the patching of WinRE images on Windows 10 and Windows 11 machines"

Also, the FAQ on the CVE article has been updated to clarify:

Can a bootable Windows ISO or USB flash drive that boot to Windows RE be used to exploit this vulnerability?
No. The exploit is only possible with the winre.wim on the recovery partition of the device.

Can a vulnerable version of WinRE WIM file be used to exploit this vulnerability?
No. A BitLocker encrypted drive cannot be accessed via an arbitrary WinRE WIM file hosted on an external drive. Please complete all steps in [Microsoft Learn | Add an Update to Windows RE | Apply the update to a running PC to ensure that the updated Windows RE image is turned on and correctly configured for your Windows installation.

A BitLocker encrypted drive cannot be accessed via an arbitrary WinRE WIM file hosted on an external drive.

Click to expand...

Is there any mention of an arbitrary winre.wim on the recov partition?

Whatsgoingon said:

Also, the FAQ on the CVE article has been updated to clarify:

Can a bootable Windows ISO or USB flash drive that boot to Windows RE be used to exploit this vulnerability?
No. The exploit is only possible with the winre.wim on the recovery partition of the device.

Click to expand...

Good. That's the clarification and specific language I was seeking in an earlier post. I'll just continue with "reagentc /disable".

I wonder if you have noticed that Microsoft has once more updated the FAQ on this and surprisingly added:

If TPM+PIN BitLocker protectors are being used, can the vulnerability be exploited if the attacker does not know the TPM PIN?

No. To exploit the vulnerability the attacker needs to know the TPM PIN if the user is protected by the BitLocker TPM+PIN.

Click to expand...

Surprisingly, because, if the recovery environment start is initiated from the OS, the the PIN is not asked for; same behavior as without a PIN. So how could that make a difference, then?

Well, well... yesterday, MS has even issued a script for patching WinRE - so some months later, they finally deliver all the pieces. Remember, these are the guys you trust to design and maintain your OS. KB5025175: Updating the WinRE partition on deployed devices to address security vulnerabilities in CVE-2022-41099 - Microsoft Support

Microsoft has developed a sample PowerShell script that can help you automate updating the Windows Recovery Environment (WinRE) on deployed devices to address the security vulnerabilities in CVE-2022-41099.

Click to expand...

Comport Colin said:

Well, well... yesterday, MS has even issued a script for patching WinRE - so some months later, they finally deliver all the pieces. Remember, these are the guys you trust to design and maintain your OS. KB5025175: Updating the WinRE partition on deployed devices to address security vulnerabilities in CVE-2022-41099 - Microsoft Support

Click to expand...

Just a small drop in the ocean, as Secure Boot and Windows Measured Boot with TPM 2.0 can be bypassed regardless of whether you use BitLocker. I actually never trusted them BTW, as I don't use Windows for anything besides my personal hobby laptop because company policy does not allow.

P.S., last Christmas there was this guy on here who actually did post a warning against keeping WinRE on the OS drive, but I can't seem to recall his name. Or wait, I think I just found who it was.

Thanks for pointing out that Microsoft now has a script available to patch Win RE on installed Windows deployments. I have added a note to the top of my procedure (post #24 in this thread) to recommend that this new Microsoft script be used rather than following my procedure now.