When Windows updating goes bad — the case of the problematic patch

Every month, Windows users and administrators receive updates from Microsoft on Patch Tuesday (or Wednesday, depending on where you’re located). And each month, most users all apply the same updates. 

But should we?

Case in point: KB5012170, a patch released on Aug. 9 that either causes no issues — or triggers Bitlocker recover key requests or won’t install at all, demanding that you go find a firmware update. This patch, called the Security update for Secure Boot DBX, applies to nearly all supported Windows releases. Specifically, it affects Windows Server 2012; Windows 8.1 and Windows Server 2012 R2; Windows 10, version 1507; Windows 10, version 1607 and Windows Server 2016; Windows 10, version 1809 and Windows Server 2019; Windows 10, versions 20H2, 21H1, and 21H2; Windows Server 2022; Windows 11, version 21H2 (original release), and Azure Stack HCI, version 1809, all the way to Azure Stack Data Box, version 1809 (ASDB).

Whew.

But here’s the thing: not all machines share the same risk factors. This specific update deals with a security risk where “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.”

As noted in the Microsoft guidance: “To exploit this vulnerability, an attacker would need to have administrative privileges or physical access on a system where Secure Boot is configured to trust the Microsoft Unified Extensible Firmware Interface (UEFI) Certificate Authority (CA). The attacker could install an affected GRUB and run arbitrary boot code on the target device. After successfully exploiting this vulnerability, the attacker could disable further code integrity checks, thereby allowing arbitrary executables and drivers to be loaded onto the target device.”

I don’t recommend ignoring or blocking updates unless the risk of side effects is greater than the patch itself.  In this specific case, the attacker has to have one of two things to occur.

1. They have to have physical access to the machine. For the typical home or consumer user, this risk is low. Attackers would have to break into your house first and then attempt to bypass the bootloader of your operating system. In reality, they’re more likely to steal your television, look for cash, or grab other valuables. It would be much easier for the attacker to steal your computer or your hard drive.
2. They have to have administrative rights to your computer. For the average user, if an attacker has administrative rights to the system already, they are there monitoring usernames and credentials to banking sites and other sensitive information.

I’ve yet to be convinced that for most home users the risk to these machines warrants the installation of this patch. Too often, we’ve seen side effects that are just as impactful as the risk of attack itself. As noted in the Eclypsium blog: “In April 2019, a vulnerability in how GRUB2 was used by the Kaspersky Rescue Disk was publicly disclosed. In February 2020, more than six months after a fixed version had been released, Microsoft pushed an update to revoke the vulnerable bootloader across all Windows systems by updating the UEFI revocation list (dbx) to block the known-vulnerable Kaspersky bootloader. Unfortunately, this resulted in systems from multiple vendors encountering unexpected errors, including bricked devices, and the update was removed from the update servers.”

So when KB5012170 was released to certain machines, it was offered to all machines — including virtual ones (even those using Legacy BIOS settings). While the vast majority installed the update just fine, there were some machines explicitly blocked, though including HP Elite series without DBXEnabled,  FUJITSU FJNBB38 and Mac Boot Camp.. KB5012170 gets 

The three boot loaders that are vulnerable include CryptoPro Secure Disk, another is a testing tool and disk wiper called Eurosoft UK, the last, Reboot Restore Rx Pro, is used to revert changes in a PC after a reboot in a classroom, kiosk PCs, hotel guest PCs, etc.. Even if you aren’t using these three vulnerable loaders, you will get this “BIOS update.”

But the side effects can be disastrous. Just ask Mike Terrill, who writes Mike’s Tech Blog, who explained recently how the bad side of patching played out for him. Most likely, he had a computer like certain Dells or HP models that set up Bitlocker on their C: drive and then didn’t prompt them to save the recovery key to a backup location the person knows about. (Normally, when Bitlocker is set up with either an Azure active directory account or a Microsoft account, the Bitlocker recovery key is saved and you can log in and find it. But certain machines turn on drive encryption and don’t back up the key; you reboot your system after installing KB5012170 and it asks for a recovery password you don’t have.)

Some users have reported that following these steps allowed them to boot successfully into the operating system:

1. Restart your computer.
2. When you see your device’s logo on screen, keep tapping F2.
3. Enter the BIOS screen.
4. Under General, select Boot Sequence.
5. Then select UEFI and under Security, select TPM 2.0 Security.
6. Choose Enable and click on Apply.
7. Under “Secure Boot,” select Secure Boot Enable.
8. Click on Apply. Then restart the system.

All of this is designed to highlight why you shouldn’t assign the same level of risk to every update. In this example, installing the update and triggering the request for a bootlocker recovery password you don’t know causes as much damage, if not more, than the issue being fixerd. 

Microsoft has to acknowledge and provide more support for updates that trigger side effects and warn users. It’s not enough to document the concerns in a Known Issues section — users need to be assured patches won’t damage their systems.  Users on  standalone machines should be prompted to enter a Bitlocker recovery key before these kind of updates to ensure they have the key. If they cannot do so, the update should prompt them through the process of either disabling Bitlocker or resetting the Bitlocker recovery key.

Patches shouldn’t hurt. This isn’t the first time that a secure boot patch has triggered additional pain and damage, but it should be the last.