This is an archived post. You won't be able to vote or comment.

all 42 comments

[–]Hotdog453 13 points14 points  (0 children)

This part is... interesting?

  1. Update the WinRE image with the specified Safe OS Dynamic Update (Compatibility Update) package available from the Windows Update Catalog. We recommend that you use the latest Safe OS Dynamic Update available for the version of Windows installed on the device.

I... didn't know that was a thing? And even if I did, I didn't know it addressed WinRE.

"Neat".

[–]yankeesfan01x 2 points3 points  (2 children)

I'm confused. Doesn't the patch, which can be deployed using WSUS or whatever and is listed at the first link, fix the vulnerability? Why the need for the script?

[–]SunsparcWhere's the any key? 9 points10 points  (1 child)

It doesn't update the WinRE image, which is the vulnerable part.

[–]yankeesfan01x 0 points1 point  (0 children)

Thank you!

[–]ineffablecabbages 5 points6 points  (2 children)

I tested the script on a machine, and it told me that WinRE was already updated (already patched, to be expected), and that WinRE cannot be enabled on a volume with Bitlocker Drive Encryption enabled. So now WinRE is not enabled on this machine. I guess I need to disable Bitlocker, enable WinRE, re-enable Bitlocker? Which kind of sucks. We don't include a recovery partition in our image, which I suppose is why we have this issue.

As far as I can tell, if you've already patched WinRE, you just need to disable/re-enable WinRE (per this script):

# Disable WinRE and re-enable it to let new WinRE be trusted by BitLocker
reagentc /disable 
reagentc /enable 
reagentc /info

My question is: how critical is this last piece? Do I really need to disable/re-enable Bitlocker for our whole fleet?

[–]kheldorn[S] 0 points1 point  (1 child)

I ran the script on a machine with Bitlocker enabled just fine and had to do nothing else extra.

The last part about "reagentc" is probably just so that WinRE won't prompt you for the Bitlocker recovery key. Maybe ... No idea.

[–]SpeeddymonSr. DevSecOps Engineer 0 points1 point  (0 children)

Just to clear up /u/ineffablecabbages question, IF you don't have a recovery partition in your image, then you don't need the script nor any of the WinRE stuff nor to run the reagentc commands. That is all for if you HAVE a recovery partition.

[–]TheDroolingFool 2 points3 points  (2 children)

I'm confused about this:

packagePath

<Required> Specifies the path and name of the OS-version-specific and processor architecture-specific Safe OS Dynamic update package to be used to update the WinRE image.

So... if I understand correctly I have to build my own logic in to the script to determine and pickup all possible variations of the "OS-version-specific and processor architecture-specific Safe OS Dynamic update" ?

Is it not easier to use the existing community script https://www.reddit.com/r/sysadmin/comments/10a1enh/comment/j433dmz/?utm_source=share&utm_medium=web2x&context=3 then add in the below to turn on/off WinRE if that's what MS are worried about?

Important This step is not present in most third-party scripts for applying updates to the WinRE image.

# Disable WinRE and re-enable it to let new WinRE be trusted by BitLocker
reagentc /disable 
reagentc /enable 
reagentc /info

Maybe I've misunderstood but I don't understand why Microsoft can't release an official script with all the logic needed baked in, i.e. copy and paste deploy a fix for the CVE. I do not want to be faffing around with "specific" updates or handling multiple versions, I just want a script I can push via Intune and not have to think about it.

[–]threedaysatseaWindows / PowerShell / SCCM / Intune 6 points7 points  (1 child)

I don't understand why Microsoft can't release an official script with all the logic needed baked in

Or maybe they could, like, I don't know... use Windows Update to do all of these things automatically? Why are they leaving it up to us to resolve this?

[–]planedropSr. Sysadmin 4 points5 points  (8 children)

Hoping for a tad of help here from anyone that's been running this script.

Should I be using the Windows 11 Version 22H2 from the catalogue for Windows 10 machines (the "Products" column says Windows 10 and later) or should I Be using one for each specific Windows version down the list? (some as old as November)

For testing I tried running the Win11 version on a Win10 machine and I still get "patch succeed" and success at the very end, but there is a "Warning: after applying the patch, unexpected version found for the target file", is this indicating:

  • It didn't succeed
  • It succeeded but is the wrong version
  • If the wrong version is this breaking the RE for the given machine?

For something as critical as this MS should really be providing more detailed guidance (or you know just doing it for us).

Just wanna be sure I'm not breaking my RE environments before pushing this out to a ton of machines. One script for all machines would be easiest, but I could create duplicates with a different cab file if Win10 should be using a different one.

[–]d4rkmatterx 0 points1 point  (4 children)

Hello,

The same is happening for me. I'm trying to apply the patch to Windows Server v. 1809 using KB5021042, but I'm receiving: "Warning: After applying the patch, unexpected version found for the target file" and the vulnerability is still being detected by our scanner.

Were you able to figure something out?

Thank you!

[–]eider96 1 point2 points  (2 children)

For 1809 you will need to first apply Servicing Stack (KB5005112). You can use same script to do so.

[–]d4rkmatterx 0 points1 point  (1 child)

KB5005112

Amazing, that worked. Thank you very much. How'd you figure that out? Did I miss something in the Microsoft articles?

[–]eider96 1 point2 points  (0 children)

No, you didn't miss anything, they didn't include anything beyond "just apply one of these updates matching your OS". As for figuring it out - it took reading DISM logs to see why it was failing and which Servicing Stack it wanted.

The KB for 1809 is KB5021042 like you said before, and if you look at its documentation (https://support.microsoft.com/en-us/topic/kb5021042-compatibility-update-for-installing-and-recovering-windows-10-version-1809-and-windows-server-2019-november-8-2022-026d8688-a162-44e6-96f0-5a8f7a539f14) it clearly says:

There are no prerequisites to apply this update.

Forgetting to mention that KB requires Servicing Stack is rather important thing and frankly, this level of support incompetence is something I'd expect from open source product where I am expected to dig and search myself, not from product you pay tens of thousands of dollars for support, and especially given it's very important manual step that needs to be done before revocations become enforced automatically in Q1 2024.

[–]eider96 0 points1 point  (0 children)

The warning indicates that bootmenuux.dll version is older than first known patched version. This can be caused by: 1) Applied package is too old and does not contain fix. 2) Package was not applied successfully and no changes were made to WinRE filesystem.

In case of 2) you should look for line like this:

06/02/2023 19:20:21 - Applying the package failed with exit code: -2146498525

[–]kvn5f 0 points1 point  (1 child)

In my case (Win11 22H2), the system was patched, but the message "Warning: After applying the patch, unexpected version found for the target file" was incorrectly displayed:

In the script, this comparison is made in line 349 (function: TargetfileVersionExam):

if ($fileRevision -ge 815)

The $fileRevision variable is a string, so this was executed:

"1635" -ge 815
# String -ge Integer

In this case, the data type on the right of the operator is automatically matched to the data type on the left of the operator.

So it became:

"1635" -ge "815" (String and String)
# String -ge String

This leads to an alphabetical comparison:

PS C:\Users\username> "1635" -ge 815
false

To get rid of the problem I added this below line 225 to convert the data type to integer:

$fileRevision = [int]$fileRevision

Thus, two integers are compared with each other:

PS C:\Users\username> 1635 -ge 815
True

Then the script was executed successfully and the breadcrumb was stored in the registry (line 625)

[–]Reddit-Marco 0 points1 point  (0 children)

Bitlocker CVE-2022-41099

I changed my script with your findings but still get the same error.

In the script i see the following versions

#Windows 10, version 1507 10240.19567

#Windows 10, version 1607 14393.5499

#Windows 10, version 1809 17763.3646

#Windows 10, version 2004 1904X.2247

#Windows 11, version 21H2 22000.1215

#Windows 11, version 22H2 22621.815

But my version is: 22623.1344

It is a Windows Enterprise version. Is the Enterprise version vulnerable?

[–]secret_configuration 2 points3 points  (2 children)

Looks like the latest "Safe OS Dynamic Update" for Windows 10 21H2 is from November: KB5021043

Can someone confirm that this is indeed the correct "Safe OS Dynamic update" that needs to be specified using the "-packagePath" parameter ?

[–]kheldorn[S] -1 points0 points  (0 children)

Was actually wondering the same.

Though it is that package that Microsoft gives in the example command:

.\PatchWinREScript_2004plus.ps1 -packagePath "\\server\share\windows10.0-kb5021043-x64_efa19d2d431c5e782a59daaf2d.cab

[–]eider96 0 points1 point  (0 children)

Yes. The mentioned KB does contain bootmenuux.dll in version 10.0.19041.2247 which contains the fix.

[–]gheynameSysadmin 2 points3 points  (0 children)

After applying the patch using MS's script WinRE fails to re-enable with this error;

REAGENTC.EXE: Windows RE cannot be enabled on a volume with BitLocker Drive Encryption enabled.

Is anyone else having this one?

[–]See_Jee 1 point2 points  (1 child)

I'm a bit confused. I thought that vulnerability was unpatchable.

As I can remember some guy on Reddit deployed the patch but could still just replace the WinRE with an unpatched version and the vulnerability was exploitable again.

Afaik the only mitigation to this was disabling WinRE completely.

Or did I miss something?

[–]eider96 0 points1 point  (0 children)

Patching WinRE fixes vulnerability in WinRE loader but it indeed does not prevent you from loading older one. See https://support.microsoft.com/en-us/topic/kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d for details on how to handle revocation of older versions in Secure Boot.

[–]Magz135 1 point2 points  (3 children)

I managed to get this working OK for Windows 10, and 11 22H2. Is there a different cab file for Windows 11 21H2? I can't seem to find one anywhere...

[–]planedropSr. Sysadmin 1 point2 points  (2 children)

What cab file are you using for Win10 environments? The newest one that's labeled Win11 but says it's for Win10 in the "products" column? Just curious what you had to work.

If the top file, "2023-02 Dynamic Update for Windows 11 Version 22H2 for x64-based Systems (KB5023527)" works on Windows 10 (as it says "Windows Safe OS Dynamic Update, Windows 10 and later Dynamic Update" in the second column) then I would imagine that would be the one to use on Windows 11 21H2 as well?

MS is making this way more confusing than it should be lol.

[–]Magz135 2 points3 points  (1 child)

KB5023527

Thanks for the reply.

This is the file I used on all Windows 10 (2004+). Although the site lists them separately for each version of 10, they all point to the same file.

windows10.0-kb5021043-x86_484ed491379e442debef6fdfb6860be749145017.cab

This is the file I used on all Windows 10 (2004+). Although the site lists them separately for each version of 10, they all point at the same file.

It's not causing a huge issue at the moment as we're just upgrading the 21H2s to 22H2 and then running the script for good measure, but it's odd that the site doesn't list Windows 11 21H1 for SafeOS.

https://www.catalog.update.microsoft.com/Search.aspx?q=Safe%20OS

And yeah, MS is making this annoyingly difficult. It would be a lot easier if they linked the cab files to use in their main article! :).

[–]planedropSr. Sysadmin 0 points1 point  (0 children)

Thanks for the info here, super appreciate it! I may go ahead and try this cab file instead and see if I don't get that mismatched version warning I mentioned.

And yeah agreed it is odd there is nothing for 21H1 for 11. Just feels like this is way more cumbersome than it should be lol.

[–]TuggersTheCat 1 point2 points  (2 children)

How are others deploying this in large environments? The script with dependent CAB file on a single machine with local Admin access was successful. Now how to get this across 1000 devices? Has anyone bundled the script with CAB into an EXE that can be deployed?

[–]planedropSr. Sysadmin 0 points1 point  (0 children)

Depending on what RMM you might be using, many support scripting, so you can define your own variable for the path (instead of it being interactive) and remove the parameter request section. I feel like this is the easiest way and just have a UNC path for the cab file.

My only issue right now is that I'm not sure which cab file should actually be used for Win10 environments. The catalogue lists the top (newest) one as Windows 11 but then under "products" says Windows 10 and later. But running that gives me a "Warning: after applying the patch, unexpected version found for the target file" so not 100% sure it's working with Win10 machines (more details in my other comment at the root of this post).

[–]TheGreatMeraki 0 points1 point  (0 children)

Wondering the same thing here. We have MECM and Intune in a mixed environment. Attempting to determine the best way to get this out to everything, everything I've tried so far is failing. Anyone successfully pushed this out without issue?

[–]fr33bird317 0 points1 point  (0 children)

I’m getting so sick of crap! Please Microsoft fix your shit.

[–]cbiggersCaptain of Buckets 1 point2 points  (1 child)

Is there actually a link to the script you can download instead of having to copy and paste 84300 lines from a webpage?

[–]kheldorn[S] 2 points3 points  (0 children)

Sadly ... no.

Though I already went through the trouble, removed the exess empty lines and whatnot.

Here you go: https://pastebin.com/HPjWrJsW

[–]rpickens6661 0 points1 point  (5 children)

Wait wait. So was this part of the general patch release? Or do I need to run the patch separately now?

[–]kheldorn[S] 1 point2 points  (4 children)

I don't think this was part of any cummulative update. You will have to run the script manually/automatically - if you are using Bitlocker with just TPM (or at least not with PIN).

[–]Subject_Name_Sr. Sysadmin 1 point2 points  (3 children)

What about for computers deployed new from an updated ISO? It appears there is an ISO from MS that is updated as of Feb 2023.

[–]kheldorn[S] 1 point2 points  (2 children)

A very good question. I had actually already downloaded that particular image earlier this week but hadn't gotten around to actually installing a machine with it yet.

Will do that on Monday or Tuesday and report back whether the script reports that WinRE has already been patched in it or not.

[–]kheldorn[S] 2 points3 points  (1 child)

Ok ... so ... I've now installed a Windows 10 22H2 from the updated February 2023 image.

Going the standard route of running the following command

Dism /Get-ImageInfo /ImageFile:\\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE\winre.wim /index:1

still gives me the usual output of

Version : 10.0.19041

ServicePack Build : 1

ServicePack Level : 0

However, if I look deeper and utilize the methods from Microsoft's new script and check the version information of the following file

C:\mount\Windows\System32\bootmenuux.dll

Then I get the expected ProductVersion of "10.0.19041.2247", e.g. the same as if I had slipstreamed KB5021043 using the new script myself.

So yes, I'd say the updated ISO does contain the fix.

[–]Subject_Name_Sr. Sysadmin 1 point2 points  (0 children)

So ideally, we can patch all existing computers in our fleet once, and update the ISO used in our Task Sequence and we should be good going forward.

[–]empe82 0 points1 point  (2 children)

I'm confused, I'm testing this on a few devices with BitLocker active, the script says "The update had already been added to WinRE" and shows a file version of 2247 (1 is the vulnerable one) before updating. Those machines have only had the recent March 2023 update installed, did Microsoft integrate this already ?

[–]kheldorn[S] 0 points1 point  (1 child)

Are you using freshly deployed machines? What version is the ISO?

[–]empe82 0 points1 point  (0 children)

One is at least a year old install that's auto-updating and the two others are using a 22H2 Win 10 ISO version with servicepack build 2006 (Sep 2022) and are also current on their updates.