No estoy listo para dar una respuesta clara a los parches de seguridad lanzados el 12 de enero, y quiero alertarle sobre una actualización específica que afecta a los servidores HyperV y algunas estaciones de trabajo para consumidores.
KB4535680, also known as the Security Update for Secure Boot DBX dated January 12, 2021, provides improvements to Secure Boot DBX for several supported versions of Windows. These include Windows Server 2012 x64 bits; 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 of 1803 x64 bits; Windows 10, version 1809 x64 bit; y Windows 10, version 1909 x64 bits. The main changes affect Windows Firmware devices based on the Unified Extensible Firmware Interface (UEFI) that can work with Secure Boot enabled. » Secure Boot Banned Signature Database (DBX) prevents loading of malicious UEFI modules; 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 states that "If Windows Defender Credential Guard (Virtual Safe Mode) is enabled, your device will reboot twice." While this doesn't appear to be a known issue, I have found that having a server with HyperV enabled affects the integrity of my VMs. In my case, rebooting the host server brought the VMs up twice in a saved state.
As a general rule of thumb, when patching a HyperV host server, it's okay to let the underlying hosted VMs "do their thing". When the HyperV host is rebooted, the virtual machine can be configured by default to come back online; the system will temporarily suspend the Hyper V Management Server, reboot the host machine, and upon reboot, reboot the virtual machines. It is normal for me to leave my virtual machines running while I reboot the host server. In this case, when the HyperV host was rebooted, the virtual machines did not return to operational condition. I had to reboot the HyperV host a third time, turn it completely off, and then manually turn it back on to get my VMs back on.
If you are installing this update on HyperV servers, plan to manually power off the virtual machine first. This ensures that the virtual machines will be in a stable state and will be powered off before the patch is installed.
Historically speaking, these DBX updates have not worked well, even on consumer machines. Previous updates have caused problems on HP systems that did not have the latest BIOS updates installed. In a document published in February 2020, HP detailed the issue. (HP and Microsoft note that "If the latest supported BIOS is not installed on the system, the installation of Windows 2004, Windows 2004 Update, or KB4524244 or KB4535680 may be blocked for the system. 'installation or download').
So what's a geek or even a non-geek to do? Remember that if you are an enterprise patcher with tools like WSUS that allow you to control and approve updates, you should carefully evaluate KB4535680 before installing it on your HyperV servers. If you feel you need to implement this due to your security practices, I recommend that you manually power off any virtual machines on your HyperV server before proceeding.
For home users, consumers, and other independent patchers, please remember that especially on the Windows 10 platform, BIOS updates are extremely important. Years ago, I would install systems and never, ever update the BIOS after the initial setup. Now, before every feature release, I go to my computer manufacturer's website and download the latest BIOS update. If you're still using Windows 10 1909 and want to skip it for now, use the Wushowhide tool to hide the update. If you're using version 2004 or later, the code is already included; therefore, this update will not be offered to you.
Bottom line, for server admins in particular: This is an update I recommend you ignore unless you clearly need it. The risk to your virtual machines is much greater than the risk of an attack, in my opinion.
<p>Copyright © 2021 IDG Communications, Inc.</p>