Secure Boot can be disabled on any retail motherboard, but a mandatory requirement for changing its state is physical presence of the user at the computer. Secure Boot prevents the execution of unsigned or untrusted program code (.efi programs and operating system boot loaders, additional hardware firmware like video card and network adapter OPROMs). In 2013, a new technology called Secure Boot appeared, intended to prevent bootkits from being installed and run. Modern PC motherboards' firmware follow UEFI specification since 2010. Russian blogger ValdikSS explained the conundrum in his April 2019 post " Exploiting signed bootloaders to circumvent UEFI Secure Boot" : If it sounds weird that Microsoft would sign a Kaspersky program - a rootkit routine, at that - it isn’t. You can mince terminology, and argue that every antivirus manufacturer does it, but any way you slice it the Kaspersky Rescue Disk program is a rootkit or, more exactly, a bootkit. Kaspersky learned of the security hole in April 2019, plugged it on systems running Kaspersky endpoint protection, but didn’t release an update to the Kaspersky Rescue Disk until August 2019.Ĭompounding the problem is the fact that Microsoft signed the old Kaspersky Rescue Disk program, so Secure Boot continued to recognize old Kaspersky Rescue Disks as valid up until earlier this month. Secure Boot is supposed to make it impossible to use a recovery disk to boot into any operating system that hasn’t been pre-approved, but this older version of the Kaspersky Rescue Disk didn’t follow the Secure Boot rules. The problem is that an older version of the Kaspersky Rescue Disk allowed attackers with physical access to your machine to boot the PC into a potentially harmful operating system, even if you have Secure Boot enabled. In order to use the Kaspersky Rescue Disk, like other recovery boot disks, you have to have physical access to the PC. Kaspersky, like other antivirus companies, includes the ability to create a boot disk - in this case, the “Kaspersky Rescue Disk” - that’ll let you boot your computer even if your PC’s internals have been compromised. That brings us to the sausage-making part of the story. It didn’t take long for the Twitterverse to point the finger at Kaspersky as the source of the faulty UEFI boot manager, but why would Microsoft issue a separate Windows patch (actually, two patches) specifically to block Kaspersky's product? And what had Kaspersky done to deserve such treatment? So what, really, was being patched in KB 4524244? The official description then, and even now, has very little substance. It took ten months to push a fix - and a buggy fix at that. Microsoft has known about the UEFI loader security problem since April 2019, if not earlier. The patch was first created in September 2019, so it was in testing for almost 5 months, and that still was not enough to get it right. The files inside the patch were dated September 2019 - five months ago. You might restart into recovery with “Choose an option” at the top of the screen with various options or you might restart to your desktop and receive the error “There was a problem resetting your PC”. Using the “Reset this PC” feature, also called “Push Button Reset” or PBR, might fail. There’s a second bug in the patches, identified separately in the Windows Release Information status page: HP owners with Secure Boot enabled (more about that later) reported that their PCs wouldn’t reboot normally and, when forced, the HP BIOS said it detected an unauthorized change to the secure boot keys and had to restore. The patch wreaked havoc on many PCs, most notably HP PCs with Ryzen processors. But the Win8.1/1507 patch had the same bugs and met the same fate as its more illustrious co-conspirator, KB 4524244. That buggy patch was accompanied by a parallel patch for older versions of Windows, KB 4502496, called “Security update for Windows 10, version 1507, Windows 8.1, RT 8.1, Server 2012 R2, and Server 2012: February 11, 2020.” This time the name was correct. Win10 version 1909 wasn’t mentioned in the KB article, but the 1909 patch appeared in the Microsoft Catalog. The Knowledge Base article title was clearly wrong.From the KB article:Īddresses an issue in which a third-party Unified Extensible Firmware Interface (UEFI) boot manager might expose UEFI-enabled computers to a security vulnerability. It appeared to be directed at one wayward UEFI boot manager.They’re almost invariably rolled into cumulative updates. We don’t get standalone security patches anymore.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |