WinRE Patching – Round 2

WinRE Patching – Round 2

 , , , , , , , ,

Exactly 12 months after Microsoft released the patch for CVE-2022-41099 (see my blog about it), we get CVE-2024-20666 – a very similar problem. Like then, this patch requires a change to WinRE. The big kicker here is that Microsoft decided to include the fix for WinRE in some of the cumulative updates! Join me as I analyze the status quo and possible workarounds around this.

What is WinRE and why does it need patching?

Well, WinRE is the short handle Windows Recovery Environment. If you’re thinking “That sounds a lot like WinPE (Preinstallation)” you’d be right. The two are very much related and handled, because they share the same core. Except that once you apply the OS, WinPE disappears, but everything else keeps living alongside WinRE. To do that it needs to have a place to live: the recovery partition. Now, the recovery partition is special in that its formatted using a GPT GUID1. The GUID will hide the drive and make it so that it can’t be modified using things like diskmgmt.msc.

If we take a look at the “Desktop manufacturing” learning page, there is a lot of information on how to properly customize a WinRE. There is also a lot to learn here and if you want to know more in detail: I recommend reading those pages. The article is in this category for a reason. Microsoft probably expects that only manufacturers and enterprise companies want to change their recovery image this way. Three patches were released over the last 12 months. Two of them fix a BitLocker bypass, and one is required to apply CVE-2023-24932, a secure boot bypass, to still allow the recovery partition to boot successfully. Microsoft delivered these patches in the form of SafeOS or LCU updates that administrators had to apply manually to the operating system. (By the way, I wrote a script to make this a lot easier.)

Microsoft current approach

Microsoft took two different approaches to fixing the CVE.

  1. Windows 11 22H2 and 23H2 have the fix included in their monthly cumulative update. If the WinRE patch attempt fails, so does the CU!
  2. Every other currently supported operating system has received a separate (security) patch. Meaning if it fails, every other security update will still be applied.

Why is 0x80070643 such a common error?

Short answer: Because your WinRE might be in a bad place right now. There are ways to fix this, though – they’re just not pretty. Most admins I know would struggle to apply them on a large scale.

Longer answer: Your recovery partition isn’t big enough, and that means the update can’t apply the fix. Now, we can definitely make the recovery partition bigger. But first, we need to make sure it lives in a good neighborhood where rebuilding is possible. Let us take a closer look at common partitioning scenarios. You can compare them using diskmgmt.msc or diskpart. I’ll rank them by how easy they are to fix and how to fix them.

Here be dragons

This section contains the different scenarios and how to fix them. Please be careful and again: Test this thoroughly before going into production. If you are not a professional, do not attempt to change your partitioning unless you have tested it first!

Before you begin a couple gotchas.

  • If your recovery partition is indeed successfully activated (using reagentc /info) there will be no WinRE.wim in %SYSTEMROOT%\System32\Recovery because it has been moved to the partition.
  • The location of the WinRE.wim doesn’t have to be in the Windows path – the file %SYSTEMROOT%\System32\Recovery\ReAgent.xml, which is always in the same place, will contain an attribute called WinreLocation with the last used path. This information exists regardless of whether the recovery partition is enabled or WinRE.wim is present.
  • You need to mount WinRE to verify if the SafeOS update has been correctly applied. You can use the following (modified) line from my script to verify if it was successful (if you don’t want to use my script that is 🙂 )
$MountDirectory = 'C:\mount\'
$PackagePathKB = 'KB5034232'
(Get-WindowsPackage -Path $MountDirectory | Where-Object { $_.PackageName -like "*$PackagePathKB*" }).packagestate -eq "Installed"

Common Scenarios

Easy to fix. Microsoft recommends this layout (MSR is invisible to diskmgmgt.msc). The formatting should look like this if it was manually installed via media.

  • Run the script using -RecoveryDriveSizeInGB 1GB

Easy to fix. Yes, really. Please verify using reagentc /info that the recovery partition is actually correct. In this example it should be ‘\partition5\’. This happens if you use in-place upgrade from an older operating system (Hey infrastructure admins, see how I told you IPU is a good idea sometimes). If you need to extend your partition, refer to the first situation.

  • If the recovery partition is actually on ‘\partition1\’ you need to disable using reagentc /disable first
  • Delete the first recovery partition
  • Enable using reagentc /enable

Medium to fix. Requires additional steps not covered in my script.

  • Run the script using -CreateWinREDrive – by default the recovery partition will have 1GB.
  • I’ve seen the WinRE.wim missing in %SYSTEMROOT%\System32\Recovery. The script would fail if that’s the case. Grab one from a matching Windows ISO under \sources\install.wim (7zip can handle this). The folder should be 1\Windows\Recovery.

Hard to fix. Easy to fix using v3 of the script or up. This is a very common scenario for virtual machines to be able to extend the C: drive more easily. Its common with OEMs and up to Server 2019, although it has been a recommendation for more than 10 years not to do this.

  • Verify you have a current BitLocker recovery key – I’ve seen this cause BSoD and it happens randomly.
  • Run the script using -RecoveryDriveSizeInGB 1GB

Recommended steps to follow

  1. Reconnaissance by fire – the patch(es) don’t break anything. You might as well roll them out and then figure out exactly which machines you need to fix. Especially since, except for W11 22H2 and 23H2, the patch is not part of any CU, so it shouldn’t cause any more downtime than usual.
  2. If necessary, apply the script as described above. The WinRE customization script can be applied in most cases to fix the problems you see. The script doesn’t currently produce any output – test it thoroughly before deploying it! Read the logs provided by the script.

What Microsoft should’ve done (opinion piece)

First of all, I applaud Microsoft for taking this step. Last January they were faced with a security issue they had (probably) never seen before, and I don’t blame them for stumbling through it. The instructions were (and still are) unclear, especially regarding which SafeOS update contains fixes for which CVE. Microsoft is offering a remediation script that does the bare minimum. But, “One does not simply patch WinRE“, as we have just seen. But they also had time to work out a strategy that worked for the last 12 months. Looking at what we have today, putting something in the cumulative update was objectively a bad choice for a first attempt.

The current patches feel like Microsoft didn’t have telemetry around this (which, to be honest I can’t imagine). My assumption currently is, that this will cause a couple of changes

  1. Microsoft will probably rethink its approach to patching WinRE-related problems. The major concern was that they included the patch in the cumulative update instead of keeping it separate (for now). Microsoft included it because on 22H2 and 23H2 you’d always have a TPM and thus most likely BitLocker – I’m certain of that. On any other OS, I believe this is a non-issue because it doesn’t break anything (yes, I’m aware it leaves a vulnerability open, but it requires physical access).
  2. Customers will be more focused on this issue. This is a good thing! If your vendor or manufacturer hasn’t changed their GPT partitioning in at least 10 years, there is something wrong. This is especially painful for Autopilot because the recovery partition must exist for the wipe to work.
  3. OEMs will need to focus on this topic as well. I can’t imagine what it must be like to currently work in the department that builds the OSD for HP, Dell, or Lenovo…

Hopefully all of this will make for a better partitioning, awareness and less headache in the future. Happy patching!

  1. GUID Partition Table – Wikipedia ↩︎