Giveaway of the Day Forums

1. 

   mikiem2
   Moderator

   This is a bit complicated... Secure Boot *capability* is required by Win11 [it does not force you to enable it], and is probably turned on from the factory for relatively recent purchased systems. With Secure Boot the BIOS compares any bootloader it finds with a master list that's stored in the BIOS firmware -- if the list says it's a known good bootloader then the BIOS will proceed to fire it up & the OS, Windows, Linux etc. will start up. Problem is that the listing of good & bad bootloaders is out of date -- vulnerable bootloaders are unfortunately included. And at least one UEFI bootkit is able to get around Secure Boot. A bootkit like BlackLotus is able to start before Windows -- because of that, it can control Windows to an extent, and it's terribly difficult to get rid of.

   Microsoft fixed the original problem with a new bootloader, but BlackLotus for example can roll back the bootloader to an earlier, vulnerable version. The logical way to prevent that is make sure all the older, vulnerable bootloaders are listed as forbidden so Secure Boot won't run them, but there are 2 problems with that... One, manufacturers could release new BIOS firmware for everything, but most PCs / laptops are no longer supported, so manufacturers would not do that. And 2, the forbidden list is now so large that it wouldn't fit in the limited storage space used by many [most?] BIOS.

   Microsoft's solution is to use a Windows Defender Application Control policy to block vulnerable boot loaders ["Windows boot managers from the past 10+ years"], tying it to the BIOS: "When the policy is applied to a Windows system, the boot manager will “lock” the policy to the system by adding a variable to the UEFI firmware." And that opens up its own can of worms... some systems will break, and currently there is no compatible way to boot to USB sticks etc. Microsoft will slowly roll out this fix by the 1st quarter of 2024.

   Updates will be released as follows:

   Initial Deployment This phase starts with updates released on May 9, 2023, and provides basic mitigations,

   Second Deployment This phase starts with updates released on July 11, 2023, which adds additionally support mitigating the issue.

   Enforcement The final enforcement phase that will make the mitigations permanent. Tentatively scheduled for the first quarter of 2024.

   support.microsoft[.]com/en-us/topic/kb5027455-guidance-for-blocking-vulnerable-windows-boot-managers-522bb851-0a61-44ad-aa94-ad11119c5e91

   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

   Posted 1 year ago #
2. 

   mikiem2
   Moderator

   From the GOTD download page for AceThinker Screen Grabber Pro, 7/23/24:

   mike, This is way off topic. I really appreciate your knowledgeable posts here. You posted about Ashampoo back up program that Microsoft 365 Boot would make older backup media and USB flash drives not work. I asked you for a reference. I have searched (to no avail to verify your statement) and now asked on Quora.com. Info and answers imply that your statement was inaccurate.

   I didn't check out today's GOTD till after 5pm Est -- just doing mundane chores before I sat down at the PC with my 1st cup of coffee -- when I saw this post replying to another mike. Added a reply to today's page, and the one from a couple days ago for Ashampoo Backup, and figured I'd promote the original post as well, in case the mod didn't see those replies.

   For info, Googling "fix for CVE-2023-24932" [w/out quotes] gets 102k results, so there's a bit of coverage available currently, but sadly not much in the way of new info.

   Posted 1 year ago #
3. 

   mikiem2
   Moderator

   I decided to enable the update on my Win10 & Win11 dual boot VMs with Secure Boot & TPM 2.0 enabled -- I never boot my VMs to anything but that VM's copy of Windows, so not being able to use bootable USB sticks or drives is irrelevant. To enable the fix you just add a registry entry, using this command at the command prompt:

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

   Then you restart Windows, wait at least 5 minutes, then restart again. You can check Event Viewer to make sure it worked by looking for the messages here:

   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#logerrors5025885

   After enabling the fix in Win11, I was a little concerned what would happen when I fired up Win10, as they of course share the now modded boot loader & BIOS, but Win10 worked fine. Using the following command in PowerShell I was able to see Win10 itself updated its registry to show the fix was enabled.

   Get-WinEvent -ProviderName Microsoft-Windows-Kernel-boot -MaxEvents 10

   As per the above link, it showed "Windows boot manager revocation policy version 0x2000000000002 is applied."

   Posted 1 year ago #
4. 

   mikiem2
   Moderator

   I was curious what files the fix changed on the boot partition, where Windows boot loader lives, so I used Windows Windiff to compare the boot partitions on my Win11 VM VHDs [Virtual Hard Disks] from last month and today, after applying July's 2 updates and then enabling the fix. Enabling the fix *seems* to just turn on whatever flags in the registry &/or boot loader, so the boot loader will then modify the way the BIOS works with Secure Boot, getting the revocation list from the boot loader's file(s) instead of what's stored in the BIOS itself. The difference in files is *probably* a combination of the July update plus enabling the fix -- if I'd thought of this earlier I could have saved a copy of the boot partition after the July updates but before enabling the fix to be certain.

   EFI\boot\bootx64.efi different (L:\EFI is more recent)
   EFI\microsoft\boot\bcd different (L:\EFI is more recent)
   EFI\microsoft\boot\bcd.log different(both have identical times)
   EFI\microsoft\boot\bootmgfw.efi different (L:\EFI is more recent)
   EFI\microsoft\boot\bootmgr.efi different (L:\EFI is more recent)
   EFI\microsoft\boot\bootstat.dat different (L:\EFI is more recent)
   EFI\microsoft\boot\memtest.efi different (L:\EFI is more recent)
   EFI\microsoft\boot\skusipolicy.p7b only in L:\EFI

   Posted 1 year ago #
5. 

   mikiem2
   Moderator

   Checking to see if Microsoft has released anything yet re: WinPE, or anything related for that matter, I came across a few posts talking about updating existing media. Also found a notice on a Microsoft site that said to make sure to update WinPE after the May, 2023 update. Far as I can tell, doesn't work, though it may be needed for a next step. Downloaded the web setup files for the Windows ADK & WinPE add-on, which said I still had the latest version [from last year]. Mounted the WinPE.wim from the ADK, applied the latest Win11 22h2 cumulative update, then saved the .wim file, re-created the WinPE folder, and created a WinPE ISO from that. The .wim file grew to almost twice its original size, and worked with my VMs that hadn't had the secure boot update activated, but failed with the one that had it enabled.

   Posted 1 year ago #

RSS feed for this topic

Reply

You must log in to post.