KB5042562: Guidance for blocking rollback of Virtualization-based Security (VBS) related security updates (2024)

In this article

• Summary

• Scope of Impact

• Available mitigations

• Understanding mitigation risks

• Mitigation deployment guidelines

  • Deploying an audit mode policy

  • Deploying a Microsoft-signed revocation policy (SKUSIPolicy.p7b)

  • ​​​​​​​ Updating external boot media

• Windows Event logs

  • Policy activation events

  • Audit and block events

• Policy removal and recovery procedure

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 inCVE-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 isRunning, 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.

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 afterAugust 13, 2024and 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 theUpdating 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.p7bis 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 WindowsRE.

• 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%​​​​​​​

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 Removal and Recovery Procedure

If something goes wrong after applying the mitigation, you can use the following steps to remove the mitigation:

1. Suspend BitLocker if it is enabled. Run the following command from an elevated Command Prompt window:

   Manager-bde -protectors -disable c: -rebootcount 3

2. 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.

3. Remove the SkuSiPolicy.p7bpolicy.

   1. Start Windows normally and then sign in.

      TheSkuSiPolicy.p7bpolicy must be removed from the following location:

      • ​​​​​​​<EFI System Partition>\Microsoft\Boot\SKUSiPolicy.p7b​​​​​​​

   2. Run the following script from an elevated Windows PowerShell session to clean up policy from those locations:

      $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

4. Turn onSecure BootfromBIOS.

   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.

5. Turn on BitLocker. Run the following command from an elevated Command Prompt window:

   Manager-bde -protectors -enable c:

6. Restart your device.