Additional guidance for devices using Secure Boot to address CVE-2023-24932

@hsehestedt I wouldn't have stopped stressing over it had I not found it in black and white. But see, this brings up another question for me. If this adds something to the UEFI firmware how is that going to affect a UEFI firmware update? Maybe I'm wrong, but I've always thought that when one applies a bios update and the system reboots, while in preboot environment the flash memory in the bios chip is wiped out and updated with the new version. It would seem to me an bios update would wipe out any policy variables that MS has put in the firmware. What I can't understand is why MS is not putting these variables into TPM instead.

Yeahoww said:

That clears that up, thank you!

Click to expand...

No problem.

TheVisitor said:

This scares me, I'm not doing anything, will wait for MS to get fixes out.

Click to expand...

glasskuter said:

@hsehestedt I wouldn't have stopped stressing over it had I not found it in black and white. But see, this brings up another question for me. If this adds something to the UEFI firmware how is that going to affect a UEFI firmware update? Maybe I'm wrong, but I've always thought that when one applies a bios update and the system reboots, while in preboot environment the flash memory in the bios chip is wiped out and updated with the new version. It would seem to me an bios update would wipe out any policy variables that MS has put in the firmware. What I can't understand is why MS is not putting these variables into TPM instead.

Click to expand...

It sounds like it is a special area reserved specifically for this purpose so I'm making an assumption that this reserved area is not overwritten with a UEFI firmware update.

So when I need to reinstall Windows 11 with a new installation media, there is no need to do these changes to the new Windows installation again in order to be protected from Black Lotus?
I'm having other issues and might need to reformat soon.

Yeahoww said:

So when I need to reinstall Windows 11 with a new installation media, there is no need to do these changes to the new Windows installation again in order to be protected from Black Lotus?
I'm having other issues and might need to reformat soon.

Click to expand...

To the best of my understanding, I believe that to be correct. I plan to do some extensive testing, but I'm holding off for now.

Some new info:

On the download page for the Windows ADK and Windows PE add-on, I just noticed this note:

Important

The May 9, 2023 Windows security updates should be applied to the Windows PE add-on for the Windows ADK, for Windows 11 version 22H2 and earlier, for Windows Server 2022, and for Windows 10 version 2004 and earlier. After downloading and installing the Windows PE add-on for the Windows ADK, either update the Windows PE add-on once, or create bootable Windows PE media and apply Windows update to the Windows PE media.

I'm going to try this later today. Note: It's about 4:00 AM where I am, so it's going to be a while before I do so.

Setting up to start some testing but I have some initial observations:

I notice that when I run Macrium Reflect and choose the option to create recovery media I have no option to create media based upon Windows RE now. Since WiFi is only supported with WinRE boot media, this means that you will have no option to create media that supports WiFi (for now).

Also, when I choose to create Windows PE based recovery media, Macrium Reflect does not seem to recognize the fact that I already have Windows PE installed. Instead, it insists that it download Windows PE from Microsoft and then create the Reflect boot media from that. The implication of this is that even if you patch Windows PE on your system, the boot media created by Reflect will have to be patched separately because it won't use the patched files on your system

I'm feeling a little lazy today so I don't know if I will get through all the patching and testing today but I'll post some detailed procedures once all done.

Yeahoww said:

So when I need to reinstall Windows 11 with a new installation media, there is no need to do these changes to the new Windows installation again in order to be protected from Black Lotus?
I'm having other issues and might need to reformat soon.

Click to expand...

Not even if you format the storage unit using the Windrows installation media - just don't use an 3rd party tool which detects the EFI partition (and remove it by accident - cause Windows installer doesn't ). Or, you'll have to create a new EFI partition with the same 3rd party tool - Disable Secure Boot to be able to reinstall Windows - mount and re-apply the certificate SKUSIPolicy.p7b manually (trough CMD) to the EFI partition. As described in the troubleshooter:


The other Boot factors will be recreated automatically, i think....

A quick update...

In my last post I noted that Win RE was no longer available for creating Macrium Reflect media. I applied the revocation to a different system and Win RE IS available on that system so I can only assume something else caused that. Sorry for the false alarm.

To avoid spamming this thread and possibly posting erroneous data, I'm going to avoid further updates until I am completely done testing.

I'll just say this for now: I was able to successfully patch the Win PE add-on. When I created boot from the updated Win PE add-on I was able to successfully boot from it, so I'm making good progress .

neves said:

Not even if you format the storage unit using the Windrows installation media - just don't use an 3rd party tool which detects the EFI partition (and remove it by accident - cause Windows installer doesn't ). Or, you'll have to create a new EFI partition with the same 3rd party tool - Disable Secure Boot to be able to reinstall Windows - mount and re-apply the certificate SKUSIPolicy.p7b manually (trough CMD) to the EFI partition. As described in the troubleshooter:

KB5025885: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932 - Microsoft Support

support.microsoft.com

The other Boot factors will be recreated automatically, i think....

Click to expand...

Yeah, I was a bit confused since you had to manually add a DWORD value to regedit when doing the fix.

Yeahoww said:

Yeah, I was a bit confused since you had to manually add a DWORD value to regedit when doing the fix.

Click to expand...

The guide is pretty straightforward - tho, it can require a basic understanding of win commands. As in, the first command - mounts the EFI Partition (since by default - it's not mounted or visible through Windows Explorer - only visible in Disk Management) and then it copies the revocation policy (SKUSiPolicy.p7b) to the Boot folder from the EFI partition (also added some screenshots in my previous post with the end result).

mountvol q: /S
xcopy %systemroot%\System32\SecureBootUpdates\SKUSiPolicy.p7b q:\EFI\Microsoft\Boot
mountvol q: /D

As for the reg value - that's what registers the revocations to be added to the black lists upon restart (since it can't be applied from Windows). If you check the same registry path now: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot - AvailableUpdates should be 0 (Default - since there's no new polices scheduled for registration).

Scott said:

So I went ahead and applied the revocations to both OS's of my dual-boot System One (Win10/11). I then made a fresh backup of Win 11 and was actually able to boot into Macrium Reflect from the boot menu and restore to that fresh backup. I feel confident I could restore to any backup available, if need be, although I didn't try it.

Click to expand...

Did your Reflect recovery medium use a WinRE or a WinPE build? If I've understood what I've read (and that's guarantied to NOT be the case) the Macrium WinPE build process downloads the WinPE ADK stuff directly from MS during that build and MS is not updating WinPE with the fix yet. I'd love to be corrected if I'm wrong since I need to use a Macrium Reflect WinPE build for my recovery media. From what I've read it sound like MS expects WinPE users to manually apply the fix, and that won't happen in Reflect WinPE recovery builds unless Macrium incorporates the applying the fix into their build process.

I've probably misunderstood a bunch of stuff here, but I'm not moving ahead with this stuff yet.

glasskuter said:

I read where these revocations are stored in a portion of flash memory in firmware but supposedly separate from UEFI bios. I've read so much I can't find it right now but will post back when I do. This is what alarmed me. I have always been under the impression the firmware was separate and apart from MS

Click to expand...

Secure boot is part of Intel Management Engine firmware. It is pre OS boot. IME has a microkernel OS that runs on the chipset for Intel systems independent of the OS. That should scare you!

pokeefe0001 said:

Did your Reflect recovery medium use a WinRE or a WinPE build? If I've understood what I've read (and that's guarantied to NOT be the case) the Macrium WinPE build process downloads the WinPE ADK stuff directly from MS during that build and MS is not updating WinPE with the fix yet. I'd love to be corrected if I'm wrong since I need to use a Macrium Reflect WinPE build for my recovery media. From what I've read it sound like MS expects WinPE users to manually apply the fix, and that won't happen in Reflect WinPE recovery builds unless Macrium incorporates the applying the fix into their build process.

I've probably misunderstood a bunch of stuff here, but I'm not moving ahead with this stuff yet.

Click to expand...

Pretty sure mine is WinRE. it's whatever the default is.

The page on the MS website where the information is on how to implement these changes manually, Microsoft state that they propose on July 11 to implement stage 2 which includes:

• Allow easier, automated deployment of the revocation files (Code Integrity Boot policy and Secure Boot disallow list (DBX)).
• New Event Log events will be available to report whether revocation deployment was successful or not.
• SafeOS dynamic update package for Window Recovery Environment (WinRE).

They also say:
"If you use Secure Boot and incorrectly perform the steps on this article, you might be unable to start or recover your device from media. This can prevent you from using recovery media, such as discs or external drives, or network boot recovery, if the media has not been correctly updated."

I'm not very sure that everyone needs to implement these changes immediately. The risk varies depending on the use cases.

Also I'm a trained IT technician and a Microsoft MCP and am not willing to be a guinea pig for MS while they finalize how they're going to complete the updates and implementation of this. Currently the timeframe for the full implementation of the changes won't be until 2024.

I'm going to wait for MS to make the changes. I don't have to worry about anyone having physical access to any of our computers.

Not sure if these weblinks have been posted already, but I have found them really helpful to understand what BlackLotus actually does to a PC. They do get technical.


Microsoft


ESET - This is a detailed walkthrough re BlackLotus

Marcus Vinicus said:

I'm not very sure that everyone needs to implement these changes immediately. The risk various depending on the use cases.

Click to expand...

Agree wholeheartedly. I see no need to rush into this. I'm doing because I am a glutton for punishment .

In the meantime, I created Macrium Reflect recovery media on a patched system and both Win RE and Win PE media booted fine. Media created using the WinPE add-on for the ADK would not boot until I patched the WinPE installation.

I wrote a procedure for doing this but I want to test it on another unpatched system to make sure every "i" is dotted and "t" crossed before I provide the step-by-step.

Bree said:

It has been updated. The MCT's products.xml now shows build 22621.1702.

<Catalog version="2.0">
<PublishedMedia id="" release="">
<Files>
<File id="">
<FileName>22621.1702.230505-1222.ni_release_svc_refresh_CLIENTCHINA_RET_x64FRE_zh-cn.esd</FileName>

Click to expand...

If you download iso direct (as I usually do), it is still on .525 with install.wim which is a PITA.

MCT gives .1702 but as install.esd. I always prefer install.wim as I often customise them. Currently creating a custom iso with .1702 and install.wim.

There are places on the internet where 1702 is available and the SHA256 hash matches what is on what used to be called MSDN.

Also, if you download the version with the ESD you can convert the ESD into a WIM by doing this...

Copy the install.esd file to a temporary folder such as C:\ISO_Files. Run this command:

dism /Export-Image /SourceImageFile:C:\ISO_Files\Sources\install.esd /SourceIndex:1 /DestinationImageFile:C:\ISO_Files\Sources\install.wim /Compress:Max /CheckIntegrity

You can repeat the same export command with the index number changed to convert additional editions of Windows. Note that the first export command will take a while but the export commands for the additional indices will complete much quicker.

If you want to convert every edition, simply put the above command in a batch file multiple time, incrementing the index number each time.

When done, you will have a new install.wim file that has all the editions that the original ESD file had in in it.

NOTE: If you are uncertain how many indices are in the original ESD file, mount the ISO image (I'll assume drive letter E: is assigned to the ISO) and run this command:

dism /Get-WimInfo /WimFile:E:\Sources\install.esd

To turn that back into an ISO image:

Copy the entire contents of the ISO image to a folder, for example C:\ISO_Files.

Replace the install.esd in the \sources folder with the new install.wim.

Use your favorite program to reburn the ISO image.

NOTE: I can't tell you what parameters to use in a particular program to make the ISO bootable, but if you have the Deployment Tools option of the Windows ADK installed, you can do this:

Go to Start > All Apps > Windows Kits > Deployment and Imaging Tools Environment (make sure to run as Administrator)

From there, issue this command:

oscdimg -m -o -u2 -udfver102 -L"VolumeName" -bootdata:2#p0,e,b"c:\ISO_Files\boot\etfsboot.com"#pEF,e,b"c:\ISO_Files\efi\microsoft\boot\efisys.bin" "c:\ISO_Files" "c:\Destination_Folder\image.iso"

NOTE: Be careful - there are places in the above that look like they should have spaces but don't. If you have the files in a location other than C:\ISO_Files, make sure to replace all three occurrences with the correct location. You can leave off the -L "VolumeName" if you do not want to assign a volume label or use "" with no name for the volume label. Finally, you can change the destination to anything you want.