Windows 10: KB4535680 Security update for Secure Boot DBX - Jan. 12

Brink · Jan 13, 2021

Security update for Secure Boot DBX: January 12, 2021

Applies to

This security update applies only to the following Windows versions:

Windows Server 2012 x64-bit

Windows Server 2012 R2 x64-bit

Windows 8.1 x64-bit

Windows Server 2016 x64-bit

Windows Server 2019 x64-bit

Windows 10, version 1607 x64-bit

Windows 10, version 1803 x64-bit

Windows 10, version 1809 x64-bit

Windows 10, version 1909 x64-bit

Summary

This security update makes improvements to Secure Boot DBX for the supported Windows versions listed in the "Applies to" section. Key changes include the following:

Windows devices that has Unified Extensible Firmware Interface (UEFI) based firmware can run with Secure Boot enabled. The Secure Boot Forbidden Signature Database (DBX) prevents UEFI modules from loading. This update adds modules to the DBX.

A security feature bypass vulnerability exists in secure boot. An attacker who successfully exploited the vulnerability might bypass secure boot and load untrusted software.

This security update addresses the vulnerability by adding the signatures of the known vulnerable UEFI modules to the DBX.

To learn more about this security vulnerability, see CVE-2020-0689 | Microsoft Secure Boot Security Feature Bypass Vulnerability.

Known issues

Issue Workaround Some original equipment manufacturer (OEM) firmware might not allow for the installation of this update. To resolve this issue, contact your firmware OEM. If BitLocker Group Policy Configure TPM platform validation profile for native UEFI firmware configurations is enabled and PCR7 is selected by policy, it may result in the BitLocker recovery key being required on some devices where PCR7 binding is not possible.

To view the PCR7 binding status, run the Microsoft System Information (Msinfo32.exe) tool with administrative permissions.

Important Changing from the default platform validation profile affects the security and manageability of your device. BitLocker's sensitivity to platform modifications (malicious or authorized) is increased or decreased, depending on inclusion or exclusion (respectively) of the PCRs. Specifically, setting this policy with PCR7 omitted, will override the Allow Secure Boot for integrity validation Group Policy. This prevents BitLocker from using Secure Boot for platform or Boot Configuration Data (BCD) integrity validation. Setting this policy may result in BitLocker recovery when the firmware is updated. If you set this policy to include PCR0, you must suspend BitLocker before you apply firmware updates.

We recommend not to configure this policy, but to let Windows select the PCR profile for the best combination of security and usability based on the available hardware on each device. To workaround this issue, do one of the following based on credential guard configuration before you deploy this update:

On a device that does not have Credential Gard enabled, run following command from an Administrator command prompt to suspend BitLocker for 1 reboot cycle:
Manage-bde âProtectors âDisable C: -RebootCount 1
Then, restart the device to resume the BitLocker protection.

Note Do not enable BitLocker protection without additionally restarting the device as it would result in BitLocker recovery.

On a device that has Credential Guard enabled, there may be multiple restarts during the update that require BitLocker to be suspended. Run the following command from an Administrator command prompt to suspend BitLocker for 3 restart cycles.Manage-bde âProtectors âDisable C: -RebootCount 3This update is expected to restart the system two times. Restart the device once again to resume the BitLocker protection.

Note Do not enable BitLocker protection without additionally restarting as it would result in BitLocker recovery.

How to get this update

Method 1: Windows Update

This update is available through Windows Update. It will be downloaded and installed automatically. 

Method 2: Microsoft Update Catalog

To get the stand-alone package for this update, go to the Microsoft Update Catalog website.

Method 3: Windows Server Update Services

This update is also available through Windows Server Update Services (WSUS).

Prerequisites

Make sure you have the lastest servicing stack update (SSU) installed. For information about the latest SSU for your operating system, see ADV990001 | Latest Servicing Stack Updates.

Restart information

Your device does not have to restart when you apply this update. If you have Windows Defender Credential Guard (Virtual Secure Mode) enabled, your device will restart two times.

Update replacement information

This update does not replace any previously released update.
Click to expand...

Source: https://support.microsoft.com/en-us/...ecure-boot-dbx

:)

CxA2016 · Jan 13, 2021

Microsoft guidance for applying Secure Boot DBX update (ADV 200011) does not work.

Microsoft guidance for applying Secure Boot DBX update (ADV 200011) does not work.

Source: Microsoft guidance for applying Secure Boot DBX update

The description under step 3 seems to be incorrect:

Set-SecureBootUefi -Name dbx -ContentFilePath .\content.bin -SignedFilePath .\signature.p7 -Time 2010-03-06T19:17:21Z -AppendWrite'

It also does not describe how to determine again whether the problem has been fixed. When I re-check the changes using the following CmdLet, I always get a "true" result.

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Corporation UEFI CA 2011'

Is the CommandLet in step 3 only an example? Which time stamp (-Time) do I have to use?

Steps 1-2 worked correctly.

Best regards

Damn_Smooth · Jan 13, 2021

Windows 8 Secure Boot Feature: Not So Secure?

Linux

Linux

Linux

Linux

Oh and OSX

Here is a statement from a Kernal Developer at Red Hat:

I'm not sure this exploits the legacy BIOS but rather it exploits the legacy boot method on MBR drives, injecting a signed key before the OS boots, which you are correct in that it has nothing to do with Windows 8. And the simplest fix would just be to require boot drives use GPT when Secure Boot is enabled in UEFI.
Click to expand...

So Linux is switching to secure boot also? Or they have to because of UEFI?

newtekie1 · Jan 13, 2021

Windows 8 Secure Boot Feature: Not So Secure?

I would appreciate your list of other OS's implementing this feature. Thanks.
Click to expand...

Linux

Linux

Linux

Linux

Oh and OSX

Here is a statement from a Kernal Developer at Red Hat:

We don't really support secure boot right now, but that's ok because you can't buy any hardware that supports it yet. Adding support is probably about a week's worth of effort at most.
Click to expand...

This exploits the legacy BIOS. Not UEFI and has nothing to do with the Windows 8 support of UEFI Secure Boot.
Click to expand...

I'm not sure this exploits the legacy BIOS but rather it exploits the legacy boot method on MBR drives, injecting a signed key before the OS boots, which you are correct in that it has nothing to do with Windows 8. And the simplest fix would just be to require boot drives use GPT when Secure Boot is enabled in UEFI.

Windows 10: KB4535680 Security update for Secure Boot DBX - Jan. 12

KB4535680 Security update for Secure Boot DBX - Jan. 12

KB4535680 Security update for Secure Boot DBX - Jan. 12

KB4535680 Security update for Secure Boot DBX - Jan. 12

KB4535680 Security update for Secure Boot DBX - Jan. 12 - Similar Threads - KB4535680 Security update

KB5012170: Security update for Secure Boot DBX: August 9, 2022 - Install error - 0x800f0922

KB5012170: Security update for Secure Boot DBX: August 9, 2022 - Install error - 0x800f0922

Secure Boot DBX update KB4575994

Secure Boot DBX update KB4575994

Secure Boot DBX update KB4575994

Issue with Secure Boot DBX update KB4575994

Issue with Secure Boot DBX update KB4575994

Issue with Secure Boot DBX update KB4575994

Security update for Secure Boot DBX