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

hsehestedt · Jan 10, 2023

EDIT: Mar 22, 2023
IMPORTANT: Microsoft now has a script available to patch the Win RE environment on running systems. I strongly suggest running their script to address this issue. Please see the Mar 22, 2023 edit at the top of post #24 in this thread for details.

If you read Shawn's post today regarding the Jan 10, 2023 Patch Tuesday Security Update, you may have noticed this note as the first thing in the post:

Reference:

KB5022303 Cumulative Update for Windows 11 Build 22621.1105 (22H2)

UPDATE 1/26: https://www.elevenforum.com/t/kb5022360-cumulative-update-for-windows-11-build-22621-1194-22h2.12214/ January 10, 2023 - KB5022303 (OS Build 22621.1105) Important: For Windows Recovery Environment (WinRE) devices, see the Special instructions for Windows Recovery Environment...

www.elevenforum.com

The gist of this that if you encrypt your OS drive with BitLocker and someone gains physical access to your computer, they could potentially exploit this vulnerability to gain access to your encrypted data. If you use BitLocker on your OS drive and you have a Recovery Partition, this affects you!

This is a pretty big deal. Unfortunately, the documentation MS has regarding this is abysmal. Let me explain.

Let's start with the actual vulnerability...

Security Update Guide - Microsoft Security Response Center

msrc.microsoft.com

The solution to this issue involves a manual procedure to update the WinRE.wim located on your recovery partition. The procedure for doing this can be found here:

Add an update to Windows RE

Add an update package to Windows RE.

learn.microsoft.com

Note that you want to follow the procedure in the section called "Apply the update to a running PC".

Now, here is where things get messy:

First, I have a Recovery Partition with a size of 633 MB. That seems to be the size that Windows is creating the partition these days. I just reinstalled a few days ago, so this is a fresh installation. Unfortunately, the procedure to update the recovery environment fails due to a lack of space. It doesn't tell you that, instead it spits out this gem of a message:

REAGENTC.EXE: Operation failed: 70

REAGENTC.EXE: An error has occurred.

Well, it turns out that I always update my Windows images and had already done so today for patch Tuesday. One of the components that I update in the WinRE.wim. So, to my thinking, I could simply take the updated WinRE.wim from my Windows image and replace the one on my recovery partition. Bzzzz, wrong answer. Next contestant!

I'll spare you a lot of techno detail here, but the mechanism for updating the WinRE.wim, according to Micosoft's own docs, is to apply the "Safe OS Dynamic Update" to the WinRE.wim image (Safe OS is another term for the Windows Recovery Environment). However, through trial and error I discovered that the update for the Recovery Environment was actually contained within the Latest Cumulative Update (LCU). Again, Microsoft's own docs show that the LCU is not applicable to the Recovery Environment, but clearly this is a load of horse manure.

Yet more: I think that I now have a procedure worked out for applying the fix to running systems. After further testing I'll post a step by step procedure here. Please note that Microsoft states that only WinRE in a running environment is affected by this issue; WinRE on your Windows images are not affected. However, since their procedures are not properly updating the Windows ISO image, any machine to which you install Windows will require that you manually fix the Recovery Environment UNLESS you break with the Microsoft documented procedures and you apply the LCU to the WinRE.wim.

I'll post more when I have this throughly worked out and debugged.

In the meantime, if anyone here might be affected by this issue, I would appreciate you letting me know if you have interest in detailed mitigation procedures. If there is interest, I'll make the extra effort to create a batch file that should automate the procedure. If there is no interest, I'll save myself the effort

.

barreleye · Jan 10, 2023

Why doesn't Microsoft update it automatically? This is absurd.

ETA: On second thought I'm not sure I even care about this if it only affects a running system. I mean, if they're already in, who cares, and if they are stuck at the Windows lock screen, they have to break through that, and if they do, again, who cares about this WinRE issue. What am I missing?

hdmi · Jan 11, 2023

hdmi · Jan 11, 2023

barreleye said:
if they are stuck at the Windows lock screen, they have to break through that

...which usually takes them 13 seconds.

barreleye said:
who cares

Caring about it is what I do for for a living. It's a boring job. But someone's got to do it. And it pays well.

hsehestedt · Jan 11, 2023

I got it all worked out. It's a serious mess. All of Microsoft's own documentation regarding how to fully update a Windows image directly contradicts some of the steps that are needed. But, I got my program updated so that it properly applies these updates to the WinRE.wim which is itself inside of the install.wim.

I may try to write some code that automatically patches the WinRE environment, I just have to find the motivation to do so

barreleye · Jan 11, 2023

Lengthy discussion beginning here:

https://www.reddit.com/r/sysadmin/comments/108gvht/_/j3s5b2y

Lots of ticked off admins, plus several wondering like me (see previous message) if this is really a huge concern, given the advisory says:

Q. Are both offline images and WinRE in a running environment affected by this vulnerability?

A. No. Only a WinRE image on a running PC is vulnerable. This can be any time a recovery or reset operation is invoked from the main OS.

Ghot · Jan 11, 2023

I have 3,700 lbs. of utter crap on my computer.
That'll teach those hackers. They'll get lost in my system and will never return..

And another one bites the dust.

mccnavy · Jan 11, 2023

OP...thanks for sharing. I looked at the instructions. When it tells you to download the update package, it means go to MS Update Catalog and search for the update, correct...in this case KB5022303? Admittedly, I've never even thought of having to update the RE image...figured that updates that affected it would be automatic. Also, on one of my machines I have a Recovery Partition (I made it exactly 1GB...maybe that's big enough), but on the other I deleted the partition and have my RE folder (with the image) on my C:drive...same commands and process though?

glasskuter · Jan 11, 2023

I read the release notes on that update this morning and wasn't smart enough to make heads or tails out of it. I ended up being totally confused about all the obscure instructions. Let me get this straight. If one does NOT use bitlocker then winRe.wim does not have to be modified and one can get into recovery as usual. Is that correct?

Hypothetical question...If one DOES use bitlocker, and one downloads a current iso, can one enter recovery using the iso boot usb drive without altering winRE.wim?

Heck, this mumbo jumbo is all the more reason to recover from a Macrium image rather than use recovery environment at all.

hdmi · Jan 11, 2023

Ghot said:
I have 3,700 lbs. of utter crap on my computer.
That'll teach those hackers. They'll get lost in my system and will never return..

And another one bites the dust.

Who knows maybe if they are the friendly type those hackers might run Disk Cleanup on your computer.

SIW2 · Jan 11, 2023

Surely just copy winre.wim to somewhwere there is space e.g. %systemdrive% then mount it, integrate the update, save and then copy it back .

Hopefully it wont be too much bigger after the update has been integrated.

hsehestedt · Jan 11, 2023

mccnavy said:
OP...thanks for sharing. I looked at the instructions. When it tells you to download the update package, it means go to MS Update Catalog and search for the update, correct...in this case KB5022303? Admittedly, I've never even thought of having to update the RE image...figured that updates that affected it would be automatic. Also, on one of my machines I have a Recovery Partition (I made it exactly 1GB...maybe that's big enough), but on the other I deleted the partition and have my RE folder (with the image) on my C:drive...same commands and process though?

That is correct - we are talking about applying the Latest Cumulative Update (LCU) in order to update the WinRE.wim.

The problem for me was 2 things:

1) I couldn't update the WinRE.wim as the Microsoft instructions stated because there was not enough room, although you would never know that was the problem from the cryptic error.

2) I apply all updates (not just LCU) to my Windows images every month to make sure all components are up to date. However, even after doing that the WinRE.wim didn't have the proper updates so that meant that any new machine I installed to would have this problem. I finally figured out that I had to apply the LCU to the WinRE.wim. Microsoft's own documentation says that the LCU DOES NOT apply to the WinRE.wim, instead, the mechanism to updating it is supposed to be the "Safe OS Dynamic Update". I modified my program to do both the Safe OS Dynamic Update and the LCU and now everything is happy.

Side note: The whole process of updating Windows images fully - and when I say fully I mean all parts of the image - has a lot of flaws in the Microsoft documentation. It took me many months of hardcore troubleshooting to get a complete procedure worked out, but every once in a while something uncovers another flaw like this issue did. However, I'm confident(ish) that I have it all working now.

hsehestedt · Jan 11, 2023

SIW2 said:
Surely just copy winre.wim to somewhwere there is space e.g. %systemdrive% then mount it, integrate the update, save and then copy it back .

Hopefully it wont be too much bigger after the update has been integrated.

Actually, the updated WinRE.wim was like a MB or so amaller than the original. So that's good. Also, you are correct, that's is basically what I did. I updated the WinRE.wim offline, assigned a drive letter to the recovery partition, deleted the original file and replaced it with the updated one. Note that all the files and folders are hidden and marked hidden / system / no indexing so you have to clear that to delete the original file, then set those attributes again on the new file. Then remove the drive letter for the recover partition again.

Serious pain in the backside. I'm thinking about writing a script to automate the whole task.

hdmi · Jan 11, 2023

glasskuter said:
I read the release notes on that update this morning and wasn't smart enough to make heads or tails out of it. I ended up being totally confused about all the obscure instructions. Let me get this straight. If one does NOT use bitlocker then winRe.wim does not have to be modified and one can get into recovery as usual. Is that correct?

Hypothetical question...If one DOES use bitlocker, and one downloads a current iso, can one enter recovery using the iso boot usb drive without altering winRE.wim?

Heck, this mumbo jumbo is all the more reason to recover from a Macrium image rather than use recovery environment at all.

Here is a solution. lol

https://www.tenforums.com/backup-restore/191428-do-not-delete-your-windows-recovery-partition-without-reading-post2407495.html#post2407495

SIW2 · Jan 11, 2023

I add updates to bootable wims often. It is automated in my script to update win7 media.

I suppose you could reagentc /disable to get it into system32\recov folder, update the thing, then reagentc /enable again.

or you could fish it out using a link something like this which is a small extract from my script that I use for win7.

Code:

@echo off
TITLE (C) SIW2 2015
SET TP=%~dp0
SET TP=%TP:~0,-1%
cd /d "%TP%"
mode con lines=40 cols=100
color 5f
 
:GETRE
setlocal enableextensions enabledelayedexpansion
echo.
echo Looking for  WinRE...
(set WREGUID=)
for /f "usebackq tokens=1,2 delims={} " %%G in (`bcdedit.exe /enum {current} ^| find "recoverysequence"`) do set WREGUID=%%H
if "%WREGUID%"=="" goto :FIXRE
echo.
(set recseqdrv=)
(set recseqpth=)
for /f "usebackq tokens=1-4 delims=[]=, " %%G in (`bcdedit.exe /enum {%WREGUID%} ^| find "device"`) do (
    set recseqdrv=%%I
    set recseqpth=%%~PJ
 )
set recseqpth=%recseqpth:~0,-1%
echo.
echo. WinRE path: %recseqdrv%%recseqpth%
echo.
if  "%recseqdrv:~1,6%"=="Device" (

 MKLINK /D "%TP%\RSD" \\?\GLOBALROOT%recseqdrv%\ >nul
 IF NOT EXIST "%TP%\RSD\%recseqpth%\WinRE.wim" GOTO :FIXRE
 attrib -S -H -R "%TP%\RSD\%recseqpth%\WinRE.wim"
 COPY /Y "%TP%\RSD\%recseqpth%\WinRE.wim" "%userprofile%\desktop\WinRE.wim" >nul
 attrib +S +H  "%TP%\RSD\%recseqpth%\WinRE.wim"
 echo winre copied to "%userprofile%\desktop\WinRE.wim"
   ) ELSE (
 IF NOT EXIST "%recseqdrv%%recseqpth%\WinRE.wim" GOTO :FIXRE
 attrib -S -H -R "%recseqdrv%%recseqpth%\WinRE.wim"
 copy "%recseqdrv%%recseqpth%\WinRE.wim" "%userprofile%\desktop\WinRE.wim" >nul
 attrib  +S +H "%recseqdrv%%recseqpth%\WinRE.wim"
 echo winre copied to "%userprofile%\desktop\WinRE.wim"
 ECHO.
  )
 
    pause
 
    :FIXRE
 
    ::some code here to run reagentc etc..

Bree · Jan 11, 2023

hsehestedt said:
I updated the WinRE.wim offline, assigned a drive letter to the recovery partition, deleted the original file and replaced it with the updated one....

...Serious pain in the backside. I'm thinking about writing a script to automate the whole task.

Maybe another option would be to first disable the recovery environment with reagentc /disable. There is only ever one copy of WinRE.wim, and it will be moved from the recovery partition to C:\Windows\System32\Recovery when it is disabled. Easier to get to and work on there, and when updated you could re-enable the recovery environment which will move the updated WinRE.wim back to the recovery partition. Easier to script that too....

(just thinking out loud, I don't need to as I don't use bitlocker)

hsehestedt · Jan 11, 2023

Bree said:
Maybe another option would be to first disable the recovery environment with reagentc /disable. There is only ever one copy of WinRE.wim, and it will be moved from the recovery partition to C:\Windows\System32\Recovery when it is disabled. Easier to get to and work on there, and when updated you could re-enable the recovery environment which will move the updated WinRE.wim back to the recovery partition. Easier to script that too....

(just thinking out loud, I don't need to as I don't use bitlocker)

That's a great idea. I'm going to try that on a machine that I have not updated yet.

In fact, that will make scripting much easier as well.

hdmi · Jan 11, 2023

hsehestedt said:
That's a great idea. I'm going to try that on a machine that I have not updated yet.

In fact, that will make scripting much easier as well.

I have been doing that for years. See my reply to @glasskuter above.

1. reagentc /disable
2. copy C:\Windows\System32\Recovery\WinRE.wim onto a Ventoy stick that uses Wimboot Plugin
3. reagentc /enable
4. delete the Recovery partition

This enables me to boot straight into the WinRE.wim file that's on the stick. On this same stick, I also keep a copy of the official Windows Installation bootable ISO file that I downloaded from Microsoft, as doing this will let me simply press the w key.

P.S., when the language selection screen of Windows Setup appears, you can press Shift + F10 to open a command prompt with admin privileges. The only reason why I also like to keep my WinRE.wim file on the same stick is just because the file is smaller than the Windows Installation bootable ISO file so, when using the Ventoy stick to boot straight into either one of these two different files, the former file loads a lot faster than the latter file does. But the end result is still the same, as both options will give me WinRE equally fine. Next, the command prompt lets me use the manage-bde utility to unlock my drive if BitLocker is enabled (which it is not, but anyway).

hsehestedt · Jan 12, 2023

hdmi said:
I have been doing that for years. See my reply to @glasskuter above.

1. reagentc /disable
2. copy C:\Windows\System32\Recovery\WinRE.wim onto a Ventoy stick that uses Wimboot Plugin
3. reagentc /enable
4. delete the Recovery partition

This enables me to boot straight into the WinRE.wim file that's on the stick. On this same stick, I also keep a copy of the official Windows Installation bootable ISO file that I downloaded from Microsoft, as doing this will let me simply press the w key.

P.S., when the language selection screen of Windows Setup appears, you can press Shift + F10 to open a command prompt with admin privileges. The only reason why I also like to keep my WinRE.wim file on the same stick is just because the file is smaller than the Windows Installation bootable ISO file so, when using the Ventoy stick to boot straight into either one of these two different files, the former file loads a lot faster than the latter file does. But the end result is still the same, as both options will give me WinRE equally fine. Next, the command prompt lets me use the manage-bde utility to unlock my drive if BitLocker is enabled (which it is not, but anyway).

I've written my own program to do similar to Ventoy, but in this instance we're talking about having to patch the WinRE.wim. It all has to be done manually because there is no Microsoft process that automatically patches this file.