For Microsoft’s January patches, no all-clear (yet)
KB4535680, also known as Security update for Secure Boot DBX: January 12, 2021, makes improvements to Secure Boot DBX for a number of supported Windows versions. These include 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; and Windows 10, version 1909 x64-bit. Key changes affect “Windows devices that [have] Unified Extensible Firmware Interface (UEFI) based firmware that can run with Secure Boot enabled.” The Secure Boot Forbidden Signature Database (DBX) prevents malicious UEFI modules from loading; this update adds additional modules to block malicious attackers who could successfully exploit the vulnerability, bypass secure boot, and load untrusted software.
The patch description notes that, “If you have Windows Defender Credential Guard (Virtual Secure Mode) enabled, your device will restart two times.” While that doesn’t sound like much of a known issue, I found that having a server with HyperV enabled affected the integrity of my virtual machines. In my case, rebooting the host server twice triggered the virtual machines to go into a saved state.
Typically, when you patch a HyperV host server, it’s normal to let the underlying hosted virtual machines “do their thing.” When the HyperV host reboots, the virtual machine can be set by default to come back online; the system will temporarily pause the Hyper V Management server, reboot the host machine, and upon reboot restart the virtual machines. It’s normal for me to leave my virtual machines running while I reboot the host server. In this case, when the HyperV host rebooted, the virtual machines did not go back into operational condition. I had to reboot the HyperV host a third time, fully shutting it down then manually turning it back on to get my virtual machines back up and running.
If you install this update on HyperV servers, plan on manually shutting down the virtual machine first. This ensures that the virtual machines will be in a stable condition – and stopped – before the patch is installed.
Historically speaking, these DBX updates have not been well behaved — even on consumer-based machines. Past updates triggered issues in HP systems that did not have the latest BIOS updates installed. In a document posted in February 2020, HP detailed the problem. (Both HP and Microsoft note that “if the latest supported BIOS is not installed on the system, then Windows 2004 installation, Windows 2004 Update, or the KB4524244 or KB4535680 update may be blocked for installation or download.”)
So what’s a geek or even a non-geek to do? Remember, if you are a business patcher with tools such as WSUS that allow you to control and approve updates, you should closely evaluate KB4535680 before installing it on your HyperV servers. If you feel you need to deploy it due to your security practices, I recommend that you manually stop any virtual machine on your HyperV server before moving ahead.
For home users, consumers, and other standalone patchers, remember that first and foremost on the Windows 10 platform, BIOS updates are extremely important. Years ago, I would install systems and never, ever install a BIOS update after the initial setup. Now, before each feature release, I go to my computer manufacturer’s website and download the latest BIOS update. If you are still on Windows 10 1909, and want to skip it for now, use the Wushowhide tool to hide the update. If you are on version 2004 or later, the code is already included; thus, this update will not be offered up to you.
Bottom line for Server Admins, in particular: This is one update I recommend you skip unless you have a clear need for it. The risk to your virtual machines is much greater than the risk from any attack, in my opinion. At a minimum, ensure that you have taken precautionary actions before you move ahead.