Microsoft Support:
Summary
Microsoft was made aware of a vulnerability in Windows that allows an attacker with administrator privileges to replace updated Windows system files that have older versions, opening the door for an attacker to reintroduce vulnerabilities to Virtualization-based security (VBS). Rollback of these binaries might allow an attacker to circumvent VBS security features and exfiltrate data that is protected by VBS. This issue is described in CVE-2024-21302 | Windows Secure Kernel Mode Elevation of Privilege Vulnerability.To resolve this issue, we will revoke vulnerable VBS system files that are not updated. Because of the large number of VBS-related files that must be blocked, we use an alternative approach to block file versions that are not updated.
Scope of Impact
All Windows devices that support VBS are affected by this issue. This includes on-premises physical devices and virtual machines (VMs). VBS is supported on Windows 10 and later Windows versions, and Windows Server 2016 and later Windows Server versions.The VBS state can be checked through the Microsoft System Information tool (Msinfo32.exe). This tool collects information about your device. After starting Msinfo32.exe, scroll down to the Virtualization-based security row. If the value of this row is Running, VBS is enabled and running.
The VBS state can also be checked with Windows PowerShell by using the Win32_DeviceGuard WMI class. To query the VBS state from PowerShell, open an elevated Windows PowerShell session and then run the following command:
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
After running the above PowerShell command, the VBS state status should be one of the following.
Field name | Status |
VirtualizationBasedSecurityStatus |
|
Available mitigations
For all supported versions of Windows 10, version 1809 and later Windows versions, and Windows Server 2019 and later Windows Server versions, administrators can deploy a Microsoft-signed revocation policy (SkuSiPolicy.p7b). This will block vulnerable versions of VBS system files that are not updated from being loaded by the operating system.Note Additional mitigations and mitigation support for all supported versions of Windows 10, version 1507 and earlier Windows versions, and Windows Server 2016 and earlier Windows Server versions are planned for future updates.
When this policy is applied to a Windows device, the policy will also be locked to the device by adding a variable to the UEFI firmware. During startup, the policy loads and Windows blocks the loading of binaries that violate the policy. If the UEFI lock is applied and the policy is removed or replaced with an older version, the Windows boot manager will not start, and the device will not start. This boot failure will not show an error and the system will proceed to the next available boot option which might result in a boot loop.
For the policy mitigation to work, the device must be updated with the Windows update released on or after August 13, 2024. If updates are missing, the device might not start with the mitigation applied or the mitigation may not work as expected. Additionally, mitigations described in KB5025885 should be applied to your device.
Important Do not apply this mitigation to Windows versions earlier than Windows 10, version 1809 or versions of Windows Server earlier than Windows Server 2019. If the mitigation is applied to devices that are unsupported, the devices will not start and you receive an error 0xc0000428. You will need to follow the instructions in the Policy removal and recovery procedure section to recover.
Understanding mitigation risks
You need to be aware of potential risks before applying the Microsoft-signed revocation policy. Please review these risks and make any necessary updates to recovery media before applying the mitigation.- User Mode Code Integrity (UMCI). The Microsoft-signed revocation policy enables user mode code integrity so that rules in the policy are applied to user mode binaries. UMCI also enables Dynamic Code Security by default. Enforcing these features may introduce compatibility issues with applications and scripts and may prevent them from running and have a performance impact on start up time. Before deploying the mitigation, follow the instructions to deploy audit mode policy to test for potential issues.
- UEFI Lock and Uninstalling updates. After applying the UEFI lock with the Microsoft-signed revocation policy on a device, the device cannot be reverted (by uninstalling Windows updates, by using a restore point, or by other means) if you continue to apply Secure Boot. Even reformatting the disk will not remove the UEFI lock of the mitigation if it has already been applied. This means that if you attempt to revert the Windows OS to an earlier state that does not have the applied mitigation, the device will not start, no error message will be displayed, and UEFI will proceed to the next available boot option. This might result in a boot loop. You must disable Secure Boot to remove the UEFI lock. Please be aware of all possible implications and test thoroughly before you apply the revocations that are outlined in this article to your device.
- External Boot Media. After the UEFI lock mitigations have been applied to a device, external boot media must be updated with the Windows updates tht are dated on or after August 13, 2024 and with the Microsoft-signed revocation policy (SkuSiPolicy.p7b). If external boot media is not updated, the device might not boot from that media. See the instructions in the Updating external boot media section before applying the mitigations.
Boot media that is updated with the Microsoft-signed revocation policy, must only be used to boot devices that have the mitigation already applied. If it is used with devices without the mitigation, the UEFI lock will be applied during startup from the boot media. Subsequent starts from disk will fail, unless the device is updated with the mitigation or the UEFI lock is removed. - Windows Recovery Environment. The Windows Recovery Environment (WinRE) on the device must be updated with the Windows updates dated on or after August 13, 2024 before the SkuSipolicy.p7b is applied to the device. Omitting this step might prevent WinRE from running the Reset PC feature. For more information, see Add an update package to Windows RE.
- Preboot Execution Environment (PXE) boot. If the mitigation is deployed to a device and you attempt to use PXE boot, the device will not start unless the mitigations are also applied to the network boot sources (root where bootmgfw.efi is present). If a device starts from a network boot source that has the mitigation applied, then the UEFI lock will apply to the device and impact subsequent starts. We do not recommend deploying mitigations to network boot sources unless all devices in your environment have the mitigations deployed.
Mitigation deployment guidelines
To address the issues described in this article, you can deploy a Microsoft-signed revocation policy (SkuSiPolicy.p7b). This mitigation is only supported on Windows 10, version 1809 and later Windows versions, and Windows Server 2019 and later Windows Server versions. Before you deploy the Microsoft-signed revocation policy (SkuSiPolicy.p7b), you should test for compatibility issues by using an audit mode policy.Note If you use BitLocker, make sure that your BitLocker recovery key has been backed up. You can run the following command from an Administrator command prompt and take note of the 48-digit numerical password:
manage-bde -protectors -get %systemdrive%
Deploying an audit mode policy
The Microsoft-signed revocation policy (SkuSiPolicy.p7b) enforces user mode code integrity (UMCI) and Dynamic Code Security. These features may have compatibility issues with customer applications. Before deploying the mitigation, you should deploy an audit policy to detect compatibility issues.You have two audit policy options:
- Use the provided SiPolicy.p7b audit policy,
- Or, compile your own audit policy binary from a provided XML file.
Windows Code Integrity will evaluate user and kernel mode binaries against the rules in the audit policy. If code integrity identifies an application or script in violation of the policy, a Windows Event log event will be generated with information about the blocked application or script and information about the enforced policy. These events can be used to determine if there are incompatible applications or scripts being used on your device. For more information, see the Windows Event logs section.
Use the SiPolicy.p7b audit policy
The SiPolicy.p7b audit policy is included in the Windows update dated on or after August 13, 2024 for all supported Windows operating systems of Windows 10, version 1809 and later Windows versions, and Windows Server 2019 and later Windows Server versions. This audit policy should only be applied to devices that have the August 13, 2024 or later Windows update installed or the audit policy may not behave as expected.
To deploy the provided SiPolicy.p7b audit policy, follow these steps:
- Run the following commands from an elevated Windows PowerShell prompt:
Code:# Initialize policy location and destination $PolicyBinary = $env:windir+"\System32\SecureBootUpdates\VbsSI_Audit.p7b" $DestinationBinary = $env:windir+"\System32\CodeIntegrity\SiPolicy.p7b" # Copy the audit policy binary Copy-Item -Path $PolicyBinary -Destination $DestinationBinary -force
- Restart the device.
- Confirm the policy is loaded in the Event Viewer by using the information in the Policy activation events section.
- Test by using applications and scripts while the policy is applied to identify compatibility issues.
- Run the following commands from an elevated Windows PowerShell prompt:
Code:# Initialize policy location $PolicyBinary = $env:windir+"\System32\CodeIntegrity\SiPolicy.p7b" # Remove SiPolicy.p7b Remove-Item -Path $PolicyBinary -force
- Restart the device.
- Confirm the audit policy is not loaded in the Event Viewer by using the information in the Policy activation events section.
Use an XML audit policy
If you use WDAC to manage applications and drivers allowed to run on your devices, you may already be using a policy named “SiPolicy.p7b”. For all supported Windows operating systems of Windows 10, version 1903 and later Windows versions, and Windows Server 2022 and later Windows Server versions, you can use the provided XML file to build and deploy an audit policy by using WDAC multiple policy format. For instructions to build and deploy the audit policy binary, see Deploying Windows Defender Application Control (WDAC) policies.
An XML file with the audit policy rules is available on devices that have the Windows update dated on or after August 13, 2024 installed. The XML file is located under “%systemroot%\schemas\CodeIntegrity\ExamplePolicies\VbsSI_Audit.xml”.
If you use the WDAC policy on Windows 10, version 1809 and earlier Windows versions, or on Windows Server 2016 and earlier Windows Server versions, then you will need to replace the existing WDAC policy with the audit policy to test for compatibility issues with the mitigation.
Deploying a Microsoft-signed revocation policy (SkuSiPolicy.p7b)
The Microsoft-signed revocation policy is included as part of the Windows update dated on or after August 13, 2024. This policy should only be applied to devices that have the August 13, 2024 or later update installed. If updates are missing, the device may not start with the mitigation applied or the mitigation may not work as expected.To deploy the Microsoft-signed revocation policy (SkuSiPolicy.p7b), follow these steps:
- Run the following commands in an elevated Windows PowerShell prompt:
Code:$PolicyBinary = $env:windir+"\System32\SecureBootUpdates\SkuSiPolicy.p7b" $MountPoint = 'C:\EFIMount' $EFIDestinationFolder = "$MountPoint\EFI\Microsoft\Boot" $EFIPartition = (Get-Partition | Where-Object IsSystem).AccessPaths[0] if (-Not (Test-Path $MountPoint)) { New-Item -Path $MountPoint -Type Directory -Force } mountvol $MountPoint $EFIPartition if (-Not (Test-Path $EFIDestinationFolder)) { New-Item -Path $EFIDestinationFolder -Type Directory -Force } Copy-Item -Path $PolicyBinary -Destination $EFIDestinationFolder -Force mountvol $MountPoint /D
- Restart your device.
- Confirm the policy is loaded in the Event Viewer by using the information in the Windows Event logs section.
- You should not remove the SkuSiPolicy.p7b revocation (policy) file after it is deployed. Your device might no longer be able to start if the file is removed.
- If your device does not start, see the Recovery procedure section.
Updating external boot media
To use external boot media with a device that has a Microsoft-signed revocation policy applied, the external boot media must be updated with the applied policy file. Additionally, it must include the Windows updates dated on or after August 13, 2024. If the media does not include the updates, the media will not start.Boot media which is updated with the Microsoft-signed revocation policy, must only be used to boot devices that have the mitigation already applied. If it is used with devices without the mitigation, the UEFI lock will be applied during startup from the boot media. Subsequent starts from disk will fail, unless the device is updated with the mitigation or the UEFI lock is removed.
Important We recommend that you Create a recovery drive before proceeding. This media can be used to reinstall a device in case there is a major issue.
Use the following steps to update the external boot media:
- Go to a device where the Windows updates released on or after August 13, 2024 have been installed.
- Mount the external boot media as a drive letter. For example, mount a thumb drive as D:.
- Click Start, type Create a Recovery Drive in the Search box, and then click Create a recovery drive control panel. Follow the instructions to create a recovery drive by using the mounted thumb drive.
- With the newly created media mounted, copy the SkuSiPolicy.p7b file to <MediaRoot>\EFI\Microsoft\Boot (for example, D:\EFI\Microsoft\Boot).
- Safely remove the mounted thumb drive.
- Go to a device where the Windows updates released on or after August 13, 2024 have been installed.
- Follow the steps in Update Windows installation media with Dynamic Update to create media that has the Windows updates released on or after August 13, 2024 installed.
- Place the contents of the media on a USB thumb drive and mount the thumb drive as a drive letter. For example, mount the thumb drive as D:.
- Copy SkuSiPolicy.p7b to <MediaRoot>\EFI\Microsoft\Boot (for example, D:\EFI\Microsoft\Boot).
- Safely remove the mounted thumb drive.
Windows Event logs
Windows logs events when code integrity policies, including SkuSiPolicy.p7b, are loaded and when a file is blocked from loading because of policy enforcement. You can use these events to verify that the mitigation has been applied.Code integrity logs are available in the Windows Event Viewer under Application and Services logs > Microsoft > Windows > CodeIntegrity > Operational > Application and Services logs > Services logs > Microsoft > Windows > AppLocker > MSI and Script.
For more information on code integrity events, see the Windows Defender Application Control operational guide.
Policy activation events
Policy activation events are available in the Windows Event Viewer under Application and Services logs > Microsoft > Windows > CodeIntegrity > Operational.CodeIntegrity Event 3099 indicates that a policy has been loaded and includes details about the loaded policy. Information in the event includes the friendly name of the policy, a globally unique identifier (GUID), and a hash of the policy. Multiple CodeIntegrity Event 3099 events will be present if there are multiple code integrity policies applied to the device.
When the provided audit policy is applied, there will be an event with the following information:
- PolicyNameBuffer – Microsoft Windows Virtualization Based Security Audit Policy
- PolicyGUID – {a244370e-44c9-4c06-b551-f6016e563076}
- PolicyHash – 98FC5872FD022C7DB400953053756A6E62A8F24E7BD8FE080C6525DFBCA38387
When the Microsoft-signed revocation policy (SkuSiPolicy.p7b) is applied, there will be an event with the following information (See screenshot of CodeIntegrity event 3099 below):
- PolicyNameBuffer – Microsoft Windows SKU SI Policy
- PolicyGUID – {976d12c8-cb9f-4730-be52-54600843238e}
- PolicyHash – 107E8FDD187C34CF8B8EA46A4EE99F0DB60F491650DC989DB71B4825DC73169D
If you have applied the audit policy or the mitigation to your device and CodeIntegrity Event 3099 for the applied policy is not present, the policy is not being enforced. Please consult the deployment instructions to verify the policy was installed correctly.
Audit and block events
Code integrity audit and block events are available in the Windows Event Viewer under Application and Services logs > Microsoft > Windows > CodeIntegrity > Operational > Application and Services logs > Microsoft > Windows > AppLocker > MSI and Script.The former logging location includes events about the control of executables, dlls, and drivers. The latter logging location includes events about the control of MSI installers, scripts, and COM objects.
CodeIntegrity Event 3076 in the "CodeIntegrity – Operational" log is the main block event for audit mode policies and indicates that a file would have been blocked if a policy was enforced. This event includes information about the blocked file and about the enforced policy. For files that would be blocked by the mitigation, the policy information in Event 3077 will match the policy information of audit policy from Event 3099.
CodeIntegrity Event 3077 in the "CodeIntegrity – Operational" log indicates that an executable, .dll, or driver has been blocked from loading. This event includes information about the blocked file and about the enforced policy. For files blocked by the mitigation, the policy information in CodeIntegrity Event 3077 will match the policy information of SkuSiPolicy.p7b from CodeIntegrity Event 3099. CodeIntegrity Event 3077 will not be present if there are not any executable, .dll, or drivers in violation of code integrity policy on your device.
For other code integrity audit and block events, see Understanding Application Control events.
Policy Removal and Recovery Procedure
If something goes wrong after applying the mitigation, you can use the following steps to remove the mitigation:- Suspend BitLocker if it is enabled. Run the following command from an elevated Command Prompt window:
Manager-bde -protectors -disable c: -rebootcount 3
- Turn off Secure Boot from the UEFI BIOS menu.
The procedure for turning off Secure Boot differs between device manufacturers and models. For help locating where to turn off Secure Boot, consult with documentation from your device manufacturer. More details can be found in Disabling Secure Boot. - Remove the SkuSiPolicy.p7bpolicy.
- Start Windows normally and then sign in.
The SkuSiPolicy.p7b policy must be removed from the following location:- <EFI System Partition>\Microsoft\Boot\SKUSiPolicy.p7b
- Run the following script from an elevated Windows PowerShell session to clean up policy from those locations:
Code:$PolicyBinary = $env:windir+"\System32\SecureBootUpdates\SkuSiPolicy.p7b" $MountPoint = 'C:\EFIMount' $EFIPolicyPath = "$MountPoint\EFI\Microsoft\Boot\SkuSiPolicy.p7b" $EFIDestinationFolder="$MountPoint\EFI\Microsoft\Boot" $EFIPartition = (Get-Partition | Where-Object IsSystem).AccessPaths[0] if (-Not (Test-Path $MountPoint)) { New-Item -Path $MountPoint -Type Directory -Force } mountvol $MountPoint $EFIPartition if (-Not (Test-Path $EFIDestinationFolder)) { New-Item -Path $EFIDestinationFolder -Type Directory -Force } if (Test-Path $EFIPolicyPath ) {Remove-Item -Path $EFIPolicyPath -Force } mountvol $MountPoint /D
- Start Windows normally and then sign in.
- Turn on Secure Boot from BIOS.
Consult with the documentation from your device manufacturer for locating where to turn on Secure Boot.
If you turned off Secure Boot in Step 1 and your drive is protected by BitLocker, suspend BitLocker protection and then turn on Secure Boot from your UEFI BIOS menu. - Turn on BitLocker. Run the following command from an elevated Command Prompt window:
Manager-bde -protectors -enable c:
- Restart your device.
Source: