Every month, Windows users and administrators receive updates from Microsoft on Patch Tuesday (or Wednesday, depending on where you are). And every month most users apply the same updates.
But should you?
Example case: KB5012170, a patch released on August 9 that either doesn’t cause any problems — either triggers Bitlocker key recovery requests, or won’t install at all, requiring you to go find a firmware update. This patch, called DBX Secure Boot Security Update, applies to almost all supported versions of Windows. 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, up to Azure Stack Data Box, version 1809 (ASDB).
Wow.
But here’s the thing: not all machines share the same risk factors. This particular update addresses a security risk where “a security feature bypass vulnerability exists in Secure Boot. A hacker who successfully exploited the vulnerability could bypass secure boot and load untrusted software. This security update addresses the vulnerability by adding the signatures of known vulnerable UEFI modules to DBX.”
As noted in Microsoft’s manual: “To exploit this vulnerability, an attacker would need to have administrative privileges or physical access to a system where Secure Boot is configured to trust the Microsoft Unified Extensible Firmware Interface (UEFI) Certificate Authority (CA) . An attacker can install an affected GRUB and execute arbitrary boot code on the target device. After successfully exploiting this vulnerability, an attacker could disable additional code integrity checks, thereby allowing arbitrary executable files and drivers to be loaded on 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 particular case, the attacker must have one of two things to happen.
- They must have physical access to the machine. For the typical home or consumer user, this risk is low. Attackers will first need to break into your house and then try to bypass your operating system’s bootloader. In reality, they are more likely to steal your TV, ask for money, or take other valuables. It would be much easier for an attacker to steal your computer or hard drive.
- They must have administrative rights on your computer. For the average user, if the attacker already has administrative rights to the system, they are there, monitoring usernames and credentials for banking sites and other sensitive information.
I’m still not convinced that for most home users the risk to these machines warrants installing this patch. Too often we’ve seen side effects that are just as impactful as the risk of the attack itself. As noted in Eclypsium blog: “In April 2019, a vulnerability in the way GRUB2 is used by Kaspersky Rescue Disk was publicly disclosed. In February 2020, more than six months after the release of a fixed version, Microsoft pushed an update to override the vulnerable bootloader on all Windows systems by updating the UEFI revocation list (dbx) to block Kaspersky’s known vulnerable bootloader. Unfortunately, this resulted in unexpected errors on systems from multiple vendors, 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 majority installed the update fine, there were some machines explicitly blocked though including the HP Elite series without DBXEnabled, FUJITSU FJNBB38 and Mac Boot Camp.. KB5012170 gets
The three boot drives that are vulnerable include CryptoPro Secure Disk, another is a testing tool and disk cleaner called Eurosoft UK, the last one, Reboot Restore Rx Pro, is used to revert changes to a computer after a reboot in a classroom, kiosk computers , hotel guest computers, etc. Even if you don’t use these three vulnerable bootloaders, you will get this “BIOS update”.
But the side effects can be disastrous. Just ask Mike Terrill, who writes Mike’s tech blog, who recently explained how the downside of corrections has affected 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 that the person knew about. (Typically, 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 I’m coming in and found it. But certain machines turn on device encryption and do not back up the key; you reboot your system after installing KB5012170 and it asks for a recovery password that you don’t have.)
Some users have reported that following these steps allowed them to boot the operating system successfully:
- Restart your computer.
- When you see your device logo on the screen, keep tapping F2.
- Enter the BIOS screen.
- Under General, select Boot Sequence.
- Then select UEFI and under Security select TPM 2.0 Security.
- Select Activate and click Apply.
- Under Secure Boot, select Secure Boot Enable.
- Click Apply. Then reboot the system.
All of this is meant to highlight why you shouldn’t assign the same risk level to every update. In this example, installing the update and triggering the bootloader recovery password request that you don’t know causes as much damage, if not more, than the problem it fixes.
Microsoft needs to acknowledge and provide more support for updates that cause side effects and warn users. It’s not enough to document concerns in the known issues section—users need to be sure that fixes won’t break their systems. Standalone machine users should be prompted to enter a Bitlocker recovery key prior to these types of updates to ensure they have the key. If they are unable to do so, the update should prompt them through the process of disabling Bitlocker or resetting the Bitlocker recovery key.
The patches should not hurt. This isn’t the first time a Secure Boot patch has caused additional pain and damage, but it should be the last.
Copyright © 2022 IDG Communications, Inc.
https://www.computerworld.com/article/3672150/when-windows-updating-goes-bad-the-case-of-the-problematic-patch.html