Every month, Windows users and administrators receive updates from Microsoft on Patch Tuesday (or Wednesday,\u00a0depending on where you’re located). And each month, most users all apply the same updates.\u00a0 <\/span><\/p>\n
![](\"https:\/\/images.idgesg.net\/images\/article\/2020\/07\/microsoft_windows_updates_cycle_arrows_laptop_mobile_phone_3x2_1200x800-100851684-large.3x2.jpg?auto=webp&quality=85,70\"\/)
<\/p>\n<\/p>\n
Credit to Author: Susan Bradley| Date: Tue, 06 Sep 2022 04:08:00 -0700<\/strong><\/p>\n Every month, Windows users and administrators receive updates from Microsoft on Patch Tuesday (or Wednesday,\u00a0depending on where you’re located). And each month, most users all apply the same updates.\u00a0 <\/span><\/p>\n But should we? <\/span><\/p>\n Case in point: KB5012170<\/a>, a patch released on Aug. 9 that either causes no issues \u2014 or triggers Bitlocker recover key requests or won\u2019t 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).<\/span><\/p>\n Whew.<\/span><\/p>\n But here’s the thing: not all machines share the same risk factors. This specific update deals with a security risk where \u201ca 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.\u201d<\/span><\/p>\n As noted in the Microsoft guidance: \u201cTo 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.\u201d<\/p>\n I don\u2019t recommend ignoring or blocking updates unless<\/em> the risk of side effects is greater than the patch itself.\u00a0 In this specific case, the attacker has to have one of two things to occur.<\/p>\n I\u2019ve yet to be convinced that for most home users the risk to these machines warrants the installation of this patch. Too often, we\u2019ve seen side effects that are just as impactful as the risk of attack itself. As noted in the Eclypsium blog<\/a>: \u201cIn 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.\u201d<\/p>\n So when KB5012170 was released to certain machines, it was offered to all machines \u2014 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,\u00a0 FUJITSU FJNBB38 and Mac Boot Camp.. KB5012170 gets\u00a0<\/p>\n 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\u2019t using these three vulnerable loaders, you will get this “BIOS update.”<\/p>\n But the side effects can be disastrous.\u00a0Just ask Mike Terrill, who writes Mike’s Tech Blog<\/a>, 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<\/a> and find it. But\u00a0certain machines<\/a>\u00a0turn on drive encryption and don\u2019t back up the key; you reboot your system after installing KB5012170 and it asks for a recovery password you don\u2019t have.)<\/p>\n Some users have reported that following these steps allowed them to boot successfully into the operating system:<\/p>\n All of this is designed to highlight why you shouldn\u2019t 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\u2019t know causes as much damage, if not more, than the issue being fixerd.\u00a0<\/p>\n Microsoft has to acknowledge and provide more support for updates that trigger side effects and warn users. It\u2019s not enough to document the concerns in a Known Issues section \u2014 users need to be assured patches won\u2019t damage their systems.\u00a0 Users on \u00a0standalone 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.<\/p>\n Patches shouldn\u2019t hurt. This isn\u2019t the first time that a secure boot patch has triggered additional pain and damage, but it should be the last.<\/p>\n http:\/\/www.computerworld.com\/category\/security\/index.rss<\/a><\/p>\n","protected":false},"excerpt":{"rendered":" Credit to Author: Susan Bradley| Date: Tue, 06 Sep 2022 04:08:00 -0700<\/strong><\/p>\n Every month, Windows users and administrators receive updates from Microsoft on Patch Tuesday (or Wednesday,\u00a0depending on where you’re located). And each month, most users all apply the same updates.\u00a0 <\/span><\/p>\n<\/p>\n