Remember the warning about how sausages are made? This is a story about making electronic sausages with lots of dirty little pieces.
First, the chronology. On the Tuesday of the February patch, Microsoft released a bizarre standalone security patch, KB 4524244, which was then called “Security Update for Windows 10, version 1607, 1703, 1709, 1803, 1809, and 1903: February 11 2020 ”. The name has changed, but support me.
Original problems with KB 4524244
This patch had all kinds of strange features that I discussed at the time:
- This is a standalone security patch. We are no longer getting standalone security patches. They are almost always integrated into cumulative updates.
- He seemed to be targeting a finicky UEFI boot manager. From the knowledge base article:
Addresses an issue in which a third-party Unified Extensible Firmware Interface (UEFI) boot manager could expose UEFI-enabled computers to a security vulnerability.
- The title of the knowledge base article was clearly wrong. The 1909 version of Win10 was not mentioned in the Knowledge Base article, but the 1909 patch appeared in the Microsoft catalog.
This 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. But the Win8.1 / 1507 patch had the same bugs and suffered the same fate as his most illustrious co-conspirator, KB 4524244.
What went wrong
The patch has wreaked havoc on many PCs, including HP computers with Ryzen processors. Owners of HP with Secure Boot enabled (more on that later) reported that their PCs would not restart normally and, when forced, the HP BIOS said so detected an unauthorized modification of secure startup keys and had to restore.
There is a second bug in the patches, identified separately in the Windows version information status page:
Using the “Reset this PC” function, also called “Push Button Reset” or PBR, may fail. You can restart in recovery with “Choose an option” at the top of the screen with various options or you can restart on your desktop and receive the error “There has been a problem resetting your PC”.
The files inside the patch were dated September 2019 – five months ago. As @ abbodi86 says on AskWoody:
The patch was first created in September 2019, so it was in testing for almost 5 months, and it still wasn’t enough to get it right.
Microsoft has known about the security issue with the UEFI charger since April 2019, if not sooner. It took ten months to push a fix – and a buggy fix to that.
Rootkits authorized by Microsoft
So what was really fixed in KB 4524244? The official description at the time, and even now, has very little substance.
It didn’t take long for Twitterverse to point the finger at Kaspersky as the source of the faulty UEFI boot manager, but why would Microsoft be issuing a separate Windows patch (actually two patches) specifically to block the Kaspersky product? And what had Kaspersky done to deserve such treatment?
This brings us to the sausage-making part of the story.
Kaspersky, like other antivirus companies, includes the possibility of creating a boot disk – in this case, the “Kaspersky Rescue Disk” – which will allow you to boot your computer even if the internal components of your PC have been compromised. To use Kaspersky Rescue Disk, like other recovery startup disks, you must have physical access to the PC.
The problem is that an old version of Kaspersky Rescue Disk allowed attackers with physical access to your machine to start the PC on a potentially dangerous operating system, even if secure booting is enabled. Secure Boot is supposed to make it impossible to use a recovery disc to boot into an operating system that has not been pre-approved, but this older version of Kaspersky Rescue Disk did not follow the rules of Secure Boot.
Kaspersky learned of the security breach in April 2019, plugged it into systems running Kaspersky endpoint protection, but did not release a Kaspersky Rescue Disk update until August 2019.
The problem is compounded by the fact that Microsoft signed the old Kaspersky Rescue Disk program, so Secure Boot continued to recognize old Kaspersky Rescue Disks as valid until the beginning of the month. You can hash the terminology and say that all antivirus manufacturers do it, but however you cut it, the Kaspersky Rescue Disk program is a rootkit or, more exactly, a bootkit.
If it sounds weird that Microsoft signs a Kaspersky program – a rootkit routine, at least – it doesn’t. Russian blogger ValdikSS explained the riddle in his April 2019 article “Leverage signed boot loaders to bypass UEFI secure boot“:
The firmware of modern PC motherboards has followed UEFI specifications since 2010. In 2013, a new technology called Secure Boot appeared, intended to prevent the installation and execution of bootkits. Secure boot prevents the execution of unsigned or untrusted program code (.efi programs and operating system boot loaders, additional hardware firmware such as the video card and network card OPROMs).
Secure boot can be disabled on any commercial motherboard, but a mandatory condition to change its state is the physical presence of the user on the computer. UEFI settings must be entered when the computer starts, and only then can the secure boot settings be changed.
Most motherboards only include trusted Microsoft keys, which forces boot software providers to ask Microsoft to sign their boot loaders. This process includes a code audit procedure and the justification of the need to sign their file with a global trust key if they wish the disk or the USB key to operate in Secure Boot mode without manually adding their key on each computer. .
Microsoft therefore signed and signed, very intentionally, rootkits. Uh, bootkits. In this way, the emergency recovery discs can work.
Revocation of the UEFI signature
Microsoft may change their minds about security authorization for their Microsoft-approved UEFI workarounds, but to do that, they need to add the application that is no longer reliable to something called UEFI revocation list file, which in turn updates the signature forbidden secure boot database.
Still with me?
Here’s the problem. KB 4524244 and KB 4502496 add the old Kaspersky Rescue Disk routine to the prohibited signature safe boot database of your PC, so that it is not recognized as a Microsoft approved application. But, for reasons that are not at all clear, bypassing UEFI secure boot restrictions has broken other programs – notably the boot routine for HP PCs with Ryzen processors. There may be other collateral damage.
Someone at Microsoft may know what happened, but they certainly don’t tell anyone.
What did Kaspersky do wrong?
Nothing. Other than the distribution of a Kaspersky Rescue Disk program, before August 2019, which could be used for harmful purposes.
Kaspersky has detailed – and, as far as I know, accurate accounting for the debacle in one Newly published FAQ.
The key conclusion, “Kaspersky products were not the cause of this problem”, referring to the bugs in KB 4524244, rings true. The problem lies in another conflict, which has not been resolved in five months of testing.
It seems that if Microsoft had just tested its patch on an HP machine with a Ryzen processor, we would not be in this mess. But … Microsoft.
And after?
Microsoft has ripped off the patch. It will not be pushed on your machine. You can’t even download it from the update catalog.
If you have installed KB 4524244 or KB 4502496 on your PC (Start> Settings> Update & security, click on Display update history) and your machine is still working, all is well. The old signature of Kaspersky Rescue Disk is in your Secure Boot Forbidden signature database and you no longer run the risk of someone slipping a malicious disk on your computer.
If you’ve installed the update and your machine won’t boot (yet another good reason to avoid installing patches right away, huh?), Microsoft has details to restore the health of your PC in the Knowledge Base Article (which now mentions Win10 version 1909) and on the Windows version information status page. The instructions tell you how to uninstall the patch. For machines with the “Reset this PC” bug, Microsoft also recommends that you follow the uninstallation with an execution of Reset this PC. I’m not sure why uninstalling the patch and running Reset puts the machines back in working order, but apparently it is.
If you haven’t installed the patch yet, be in a good mood. Microsoft will offer an appropriate fix at some point in the future. As both the knowledge base article and the version information page promise:
We are working on an improved version of this update in coordination with our partners and will release it in a future update.
Hopefully the “upgraded version” works better than the old one – and it takes less than ten months to resolve the problem. Meanwhile, ValdikSS warns in a tweet:
There are at least 2 other vuln bootloaders, not revoked.
For joy.
As far as I know, Microsoft hasn’t released any details about this fiasco, other than pulling the patch out, identifying bugs, and promising a fix. Security, meeting the dark.
Follow the play-by-play on AskWoody.com.
Copyright © 2020 IDG Communications, Inc.
