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

Ghot · May 11, 2023

I read the article yesterday, so that was like, years ago... but I seem to remember that it said the hacker needs "physical access" to the computer, to be able to make use of this exploit.

While those in a business environment should probably worry about this exploit, I don't think that regular home users need to worry about it. I could be wrong, as Microsoft doesn't speak English anymore, I may have mis-interpreted the wording.

For the BlackLotus UEFI bootkit exploit described in this article to be possible, an attacker must gain administrative privileges on a device or gain physical access to the device. This can be done by accessing the device physically or remotely, such as by using a hypervisor to access VMs/cloud. An attacker will commonly use this vulnerability to continue controlling a device that they can already access and possibly manipulate. Mitigations in this article are preventive and not corrective. If your device is already compromised, contact your security provider for help.

Me... I'm just gonna wait for the future MS patches that are referred to in the article.
Then again, I don't do a lot of the weirder stuff, some of you folks do on your computers.
I don't do VMs, Cloud, OneDrive, syncing, Teams... weird things like that.

Like I removed all the stuff with REVO Uninstaller (RED dots), when I installed Windows...

My point is that it's a lot harder to get hacked when Windows doesn't have 57 half-baked apps along for the ride.

Haydon · May 11, 2023

Applying the convoluted fix can do harm

The 'additional guidance' is not enough

MS should automate the fix with a WU

Scott · May 11, 2023

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.

jimbo45 · May 11, 2023

@BobD

It shouldn't make any difference on legacy VM's e.g your 32 bit W10 system -- Most VM systems have their own "Virtual BIOS" where when you create the VM you can specify a whole slew of "Virtual hardware" such as an emulated TPM and whether or not the VM boot should use MBR, EFI or EFI and sec boot.

I say *Shouldn't" but Ms's apparent confusion over the whole idea of VM's -- who knows !!! Ideally a VM shouldn't be able to get anywhere near the "Real BIOS" on the Mobo. However some systems can use shared memory etc to "make them more efficient" and that can open up potential loopholes.

I've got 2 or 3 XP VM's running on modern hardware running W11 Pro (latest release 25357 zn_release without any problems)

Anybody whose applied this fix -- does it prevent non Windows OS'es being booted. If a non Windows OS can be booted then it should be possible to always restore a previous image via the DD command since the bootloader is just an efi file on Disk or does this actually update the machines hardware Bios itself which is not really a good idea -- certainly not on home machines if you can't undo any changes.

This type of update seems to me to possibly run the risk of bricking a machine or consigning it to run Windows forever and as soon as hardware requirements change yet again --then one is really hosed up.

I think the incredibly tiny risk of getting a rootkit infection -- chances of those on domestic machines are getting vanishingly small --hackers have bigger and more lucrative targets to go after these days -- so I'm leaving this until people start reporting what's happening. !!!

Cheers
jimbo

BRAC · May 11, 2023

Thank heavens, my computer hasn't a clue what UEFI or secureboot is

thecaretaker · May 11, 2023

As I said earlier, I'm just a novice, a simpleton. So I have probably got this completely wrong. I posted this on my own non-tech forum.

I always thought that the BIOS was a totally separate thing from the Operating System. I'm sure it was in the early days. It just told all the cards, discs and devices how to work and basically like a set of instructions to start up.

It wasn't until I had my new system built (with Windows 11), I kept getting a pop up when the desktop appeared asking me to install the Gigabyte app centre. To stop it from popping up every time I booted up, I had to find the setting in the BIOS.

Also, on my system in the BIOS I have an option for Fast Boot and Ultrafast boot. But no matter what I did, I could never get this Ultrafast boot to work. It is supposed not show any info like enabling you to press delete to access the BIOS and jump straight to the desktop.

Yesterday, I came across a post on the internet where a user said it doesn't work if you turn hibernate off. Having an NVMe drive/stick which is lightning fast, I had also turned Prefetch and Superfetch off thinking they would just be writing and reading wearing the thing out. That's basically what I had always done with my systems over the years.

I turned them all back on and boy, does this thing start up in seconds. It's about 1 second for the memory card LEDs to come to life, 1 second for the monitor to turn on and by a total of 6 seconds I am on the desktop. The monitor is still showing it's pop-up to say it is using the Display Port (That seems to have a 5 second delay before going off). So again, it shows that the BIOS is interacting directly with the Operating System to make all this happen.

In fact, I am incorrect in calling it the BIOS, that's old hat. It is now UEFI (Unified Extensible Firmware Interface) but folk still refer to it as BIOS.

I can't help thinking, if they hadn't designed the UEFI (BIOS) to interact/communicate (work with) the OS, it might not be so vulnerable to hacks like this BlackLotus UEFI bootkit.

Things were much simpler in the days of my Commodore Vic20 and Commodore 64

MiguelAngel11 · May 11, 2023

glasskuter said:
I wouldn't dare as all this is as clear as mud to me. I'm no novice and the entire MS article is a lot of gobbly-gook to me.

Is this saying that if secure boot is on, one has to manually apply the revocations for the extra protections of the CVE to go into effect to protect the user from BlackLotus bootkit? Is it saying if the revocations ARE NOT manually applied, no harm-no foul. Booting from any external media will continue to work if one turns off secure boot?

Is this saying that if I manually apply the revocations to a secure boot system that there is no going back? Seems to me this will create a nightmare situation for repair shops who won't know if the revocations have been applied or not.

Is this saying that if secure boot is turned off, the CVE has no effect on the system?

Seems to me the CVE can cause as much trouble as BlackLotus.

I'm totally lost here and feel like a complete newbie. Until someone can explain all this in simpleton terms, my secure boot is off and will stay off. I'll take my chances that BlackLotus won't pick me as a victim.

I performed the following steps after the 9th May update

1. Deleted the Macrium Reflect inbuilt boot loader so Win 11 is the only OS
2. Applied the revocations explained KB5025885: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932 - Microsoft Support
3. Tested boot in my main with the Macrium Reflect boot loader Startup Menu and it worked fine
4. Tested with a Macrium USB disk and it worked (Secure Boot Disabled). Worked.

Just for clarification I have Secure Boot enabled in my main laptop
As glasskuter explained the MS article is very confusing.

bikemanI7 · May 13, 2023

Yeah think gonna hold of manually applying the revocations for now.

But will update Boot media shortly here for both Windows 11 Desktop and Windows 10 Gaming Laptop, and yes Microsofts KB article is kinda confusing to figure out so far lol. Yes did a Full Image backup yesterday of Windows 11 Desktop and will do a full one on Windows 10 Gaming Laptop shortly here

Scott · May 13, 2023

Not too confusing after reading it a few times, lol.

Step 3a Apply the Code Integrity Boot Policy

Elevated Command prompt, one at a time:

Code:

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

Step 3b Apply the Secure Boot UEFI Forbidden List (DBX)

Code:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x10 /f

Stpe 3c Restart the device

Step 3e Wait at least 5 minutes and then restart the device again

Set 3d Verify installation and revocation list was successfully applied

bikemanI7 · May 13, 2023

Scott said:
Not too confising after reading it a few times, lol.

Step 3a Apply the Code Integrity Boot Policy

Elevated Command prompt, one at a time:

Code:

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

Step 3b Apply the Secure Boot UEFI Forbidden List (DBX)

Code:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x10 /f

Stpe 3c Restart the device

Step 3e Wait at least 5 minutes and then restart the device again

Set 3d Verify installation and revocation list was successfully applied

Suppose i should use my Admin account when i do this task whenever i got time

Steve C · May 14, 2023

I'm not going to do anything other than rely on MS updates since no one else has physical access or admin access over the network.

Haydon · May 14, 2023

Steve C said:
I'm not going to do anything other than rely on MS updates since no one else has physical access or admin access over the network.

Yeah, and for me, no networking also means no networking on the home LAN either, always had it like that

HRPuffnstuff · May 14, 2023

Steve C said:
I'm not going to do anything other than rely on MS updates since no one else has physical access or admin access over the network.

I'm kind of leaning that way too. I've looked at the command sequence for deployment and although it seems simple enough something doesn't sit right since MS did not deploy the fix in WU.

It probably has something to do with ensuring that users have the updated installation media prior to actually doing these steps but only MS knows for sure.

hsehestedt · May 14, 2023

HRPuffnstuff said:
I'm kind of leaning that way too. I've looked at the command sequence for deployment and although it seems simple enough something doesn't sit right since MS did not deploy the fix in WU.

It probably has something to do with ensuring that users have the updated installation media prior to actually doing these steps but only MS knows for sure.

Yes, you are correct. A large part of it is that you should create updated media before you apply the revocations. It's also important to get a good full disk image backup made (assuming you have such a backup plan in place) after applying the May 9 or later updates. Finally, the update is happening in three phases.

glasskuter · May 14, 2023

@hsehestedt I'm still lost but after reading multiple times, the light is gradually coming on. I understand if I do nothing MS is eventually going to do it for me. What concerns me here and where I'm still a little confused is changes to my firmware. Disregarding this CVE, Dell has issued UEFI bios updates 13 times in the 22 months I've owned this system which concerned me in and of itself. I was hesitant but did apply them all with no trouble but that's a lot of updates for bios.

Now, with this CVE MS will also have access and make changes to an area of my firmware. If I keep secure boot turned off, does this prevent MS from implementing these revocations?
On the other hand, I guess there may come a point where MS will force us to have secure boot turned on. The way I read it even a bios password would not prevent MS getting access and making this change? Sure, I don't want a hacker inserting a bootkit, but I do not want MS anywhere near my bios either.
Of course, I can get infected, but I agree with others that the hackers are more concerned with corporate environments than with consumers. I guess I'm asking is as users, is there anything we can do to remain in complete control of what we can boot from and what we can't.
Sorry to be so obtuse about this, but sometimes it takes a sledge hammer to get through to me.

HRPuffnstuff · May 15, 2023

The instructions say to turn SB off to implement the instructions and then afterwards to turn it back on.

milkturnipsbage · May 15, 2023

This was simple enough. Just followed the steps in the tutorial.

1 . Run CMD as administrator:

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

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x10 /f

2. Reboot

3. Wait 5 minutes, then reboot again

4. Verify the update was sucessfully applied by opening Event Viewer and search for 1035:
"Secure Boot Dbx update applied successfully"

I'm now going to try to see if my installation media USB is no longer working. If that's the case I just download the mediacreationtool from Microsoft's website and create a new one?

milkturnipsbage · May 15, 2023

HRPuffnstuff said:
The instructions say to turn SB off to implement the instructions and then afterwards to turn it back on.

I did not disable SecureBoot before this and I find no mention of doing so in the instructions from Microsoft?

hsehestedt · May 15, 2023

glasskuter said:
Sorry to be so obtuse about this, but sometimes it takes a sledge hammer to get through to me.

You are not being obtuse at all! I have to admit that I too have questions about how this works.

So, what I do understand is that when you apply the revocations, you are actually making changes to the EFI partition. But that leaves some outstanding questions in my mind...

When you install Windows from scratch, what actually creates the EFI partition? I thought that it was Windows. The Microsoft KB says that even reformatting the disk will not remove the revocations but I'm trying to understand how that can be. The implication is that the revocations are stored permanently somewhere, but where exactly is that? I'm sure that Microsoft isn't flashing the BIOS on every system, so I'd like a better understanding of how this works. If you wipe the disk and recreate the EFI partition, where is it pulling the revocation information from?

Bottom line is that I too am still trying to fully understand this.

milkturnipsbage · May 15, 2023

KB5025885 isn’t the name of the actual update right? On Windows 11 OS Build 22621.1702 all I see is: KB5026372. Is that the one?

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

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computers

Well-known member

Attachments

My Computers

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computers

aka Mama Glass

My Computers

Well-known member

My Computers

Member

My Computer

Member

My Computer

Well-known member

My Computers

Member

My Computer

Similar threads