Introduction
Microsoft was made aware of a vulnerability with the Windows boot manager that allows an attacker to bypass Secure Boot. The issue in the boot manager was fixed and released as a security update. The remaining vulnerability is that an attacker with administrative privileges or physical access to the device can roll back the boot manager to a version without the security fix. This roll-back vulnerability is being used by the BlackLotus malware to bypass Secure Boot described by CVE-2023-24932. To resolve this issue, we will revoke the vulnerable boot managers.
Because of the large number of boot managers that must be blocked, we are using an alternative way of blocking the boot managers. This affects non-Windows operating systems in that a fix will have to be provided on those systems to block the Windows boot managers from being used as an attack vector on non-Windows operating systems.
More information
One method of blocking vulnerable EFI application binaries from being loaded by the firmware is to add hashes of the vulnerable applications to the UEFI Forbidden List (DBX). The DBX list is stored in the devices firmware managed flash. The limitation of this blocking method is the limited firmware flash memory available to store the DBX. Because of this limitation and the large number of boot managers that must be blocked (Windows boot managers from the past 10+ years), relying entirely on the DBX for this issue is not possible.
For this issue, we have chosen a hybrid method of blocking the vulnerable boot managers. Only a few boot managers that released in earlier versions of Windows will be added to the DBX. For Windows 10 and later versions, a Windows Defender Application Control (WDAC) policy will be used that blocks vulnerable Windows boot managers. 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. Windows boot managers will honor the policy and the UEFI lock. If the UEFI lock is in place and the policy has been removed, the Windows boot manager will not start. If the policy is in place, the boot manager will not start if it has been blocked by the policy.
Guidance for blocking vulnerable Windows boot managers
NOTE Users should be given the option to apply the variable so they can control when they are protected.
Enabling the UEFI lock will cause existing bootable Windows media to stop booting until the media is updated with the Windows updates released on or after May 9, 2023. Guidance for updating media can be found in KB5025885: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932.
-
For Secure Boot enabled systems that are only booting non-Windows operating systems
For systems that are only starting non-Windows operating systems and will never start Windows, these mitigations can be applied to the system immediately. -
For systems dual booting Windows and another operating system
For systems that start Windows, the non-Windows mitigations should only be applied after the Windows operating system has been updated to the Windows updates released on or after May 9, 2023.
Create the UEFI Lock
The UEFI Lock has two variables that are required to prevent rollback attacks in the Windows boot manager. These variables are as follows:
-
SKU SiPolicy Attributes
This policy has the following attributes:
-
Policy Type ID:
{976d12c8-cb9f-4730-be52-54600843238e}
-
Specific file name of “SkuSiPolicy.p7b”
-
Specific physical location of EFI\Microsoft\Boot
Like all signed WDAC policies, a signed SKU Policy is protected by two UEFI variables:
-
SKU_POLICY_VERSION_NAME: “SkuSiPolicyVersion”
-
SKU_POLICY_UPDATE_POLICY_SIGNERS_NAME: “SkuSiPolicyUpdateSigners”
-
-
SKU SiPolicy Variables
This policy uses two UEFI variables stored under the EFI Namespace/Vendor
GUID(SECUREBOOT_EFI_NAMESPACE_GUID):#define SECUREBOOT_EFI_NAMESPACE_GUID \
{0x77fa9abd, 0x0359, 0x4d32, \
{0xbd, 0x60, 0x28, 0xf4, 0xe7, 0x8f, 0x78, 0x4b}};
-
SkuSiPolicyVersion
-
is of type ULONGLONG/UInt64 at runtime
-
is defined by <VersionEx>2.0.0.2</VersionEx> within policy XML in the form of (MAJOR.MINOR.REVISION.BUILDNUMBER)
-
It is translated into ULONGLONG as
((major##ULL << 48) + (minor##ULL << 32) + (revision##ULL << 16) + buildnumber)
Each version number has 16 bits, so it has a total of 64 bits.
-
The newer policy’s version must be equal or greater than the version stored in the UEFI variable at runtime.
-
Description: Set’s the code integrity boot policy version.
-
Attributes:
(EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS)
-
Namespace Guid:
77fa9abd-0359-4d32-bd60-28f4e78f784b
-
Data type:
uint8_t[8]
-
Data:
uint8_t SkuSiPolicyVersion[8] = { 0x2,0x0,0x0,0x0,0x0,0x0,0x2,0x0 };
-
-
SkuSiPolicyUpdateSigners
-
Must be the Windows signer.
-
Description: Policy signer information.
-
Attributes:
(EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS)
-
Namespace Guid:
77fa9abd-0359-4d32-bd60-28f4e78f784bd
-
Data type:
uint8_t[131]
-
Data:
uint8_tSkuSiPolicyUpdateSigners[131] =
{ 0x01, 0x00, 0x00, 0x00, 0x06, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00,
0x0b, 0x00, 0x00, 0x00, 0xd0, 0x91, 0x73, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00,
0x00, 0x00, 0x00, 0x00, 0x54, 0xa6, 0x78, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00,
0x00, 0x00, 0x00, 0x00, 0x5c, 0xa6, 0x78, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00,
0x00, 0x00, 0x00, 0x00, 0x64, 0xa6, 0x78, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x0a, 0x2b, 0x06, 0x01,
0x04, 0x01, 0x82, 0x37, 0x0a, 0x03, 0x06, 0x00,
0x00, 0x00, 0x00};
-
-
Apply the DBX
We have released the DbxUpdate.bin file for this issue on UEFI.org. These hashes include all revoked Windows boot managers released between Windows 8 and the initial release of Windows 10 that do not respect the Code Integrity Policy.
It is of the utmost importance that these are applied with care because of the risk that they may break a dual boot system that uses multiple operating systems and one of these boot managers. In the short term, we recommend that for any system, these hashes be optionally applied.
