Do you remember the warning about how sausage is made? This is an electronic sausage making story with lots of dirty little things.
First, the chronology. On Patch Tuesday in February, Microsoft released a bizarre standalone security patch, KB 4524244, which was then referred to as “Security Update for Windows 10, Version 1607, 1703, 1709, 1803, 1809, and 1903: February 11, 2020”. The name has changed, but bear it with me.
The original problems with KB 4524244
This patch had all kinds of strange features like me discussed at the time::
- It is an independent security patch. We no longer receive independent security patches. They are almost always integrated into cumulative updates.
- It seemed to be aimed at a headstrong UEFI boot manager. From the KB 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. Win10 version 1909 was not mentioned in the KB article, but patch 1909 was displayed 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”. The name was correct this time. But the Win8.1 / 1507 patch had the same mistakes and met the same fate as his more famous co-conspirator KB 4524244.
What went wrong?
The patch has caused chaos on many PCs, especially on HP PCs with Ryzen processors. HP owners with Secure Boot enabled (more on this later) indicated that their PCs would not restart normally, and the HP BIOS indicated that when this was enforced detected an unauthorized change to the secure startup key and needed to restore it.
There is a second bug in the patches, which is in the Status of Windows version information Page:
Using the “Reset this PC” function, also called “Push Button Reset” or “PBR”, may fail. You can restart the restore with “Choose an option” at the top of the screen with various options or you can restart your desktop and get the error message “There was a problem resetting your PC”.
The files in the patch were dated September 2019 – five months ago. How @ abbodi86 says on AskWoody::
The patch was first created in September 2019, so it was tested for almost 5 months and that was still not enough to get it right.
Microsoft has known the security issue of the UEFI loader since April 2019, if not earlier. It took ten months to find a solution – and a faulty one at that.
Rootkits authorized by Microsoft
So what was really patched in KB 4524244? The official description then and then has very little substance.
It did not last long Twitterverse to show the finger at Kaspersky as the source of the faulty UEFI boot manager, but why should Microsoft issue a separate Windows patch (actually two patches) to specifically block Kaspersky’s product? And what had Kaspersky done to deserve this treatment?
That brings us to the sausage making part of history.
Like other antivirus companies, Kaspersky offers the option of creating a startup disk – in this case the “Kaspersky Rescue Disk” – which you can use to start your computer even if your PC’s internals have been compromised. To use the Kaspersky Rescue Disk like other recovery boot disks, you must have physical access to the PC.
The problem is that an older version of Kaspersky Rescue Disk allowed attackers with physical access to your computer to start your PC in a potentially malicious operating system, even if you activated Secure Boot. Secure Boot is said to make it impossible to use a recovery diskette to boot an operating system that has not been pre-approved, but this older version of Kaspersky Rescue Disk did not follow the Secure Boot rules.
Kaspersky found out about the vulnerability in April 2019 and connected it to systems with Kaspersky endpoint protection, but only released an update for the Kaspersky Rescue Disk in 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 this month. You can shred the terminology and argue that any antivirus company does, but however you split it up, the Kaspersky Rescue Disk program is a rootkit, or more precisely, a bootkit.
If it sounds strange that Microsoft is signing a Kaspersky program – a rootkit routine – this is not the case. Russian blogger ValdikSS explained the riddle in his April 2019 post, “Exploit signed bootloaders to bypass UEFI Secure Boot“”::
The firmware of modern PC motherboards has been in compliance with the UEFI specification since 2010. In 2013, a new technology called Secure Boot was introduced to prevent boot kits from being installed and running. Secure Boot prevents the execution of unsigned or untrusted program code (.efi programs and boot loader of the operating system, additional hardware firmware such as graphics card and network adapter OPROMs).
Secure Boot can be disabled on any retail motherboard. However, a mandatory requirement for changing the status is the physical presence of the user on the computer. The UEFI settings must be entered when the computer boots. Only then can the settings for the safe start be changed.
Most motherboards only contain Microsoft keys that are trusted, forcing bootable software vendors to ask Microsoft to sign their boot loaders. This process includes the code audit process and the justification for the need to sign the file with a globally trusted key if the hard drive or USB flash is to work in secure boot mode without manually adding the key to each computer .
Microsoft therefore intentionally has and signs rootkits. Um, boot kits. This is how disaster recovery media can work.
Revocation of the UEFI signature
Microsoft may change its mind about the security clearance of its Microsoft-approved UEFI bypass programs at any time. To do this, however, it has to add the untrustworthy app to a so-called app UEFI blacklist file, This updates the Secure Boot Forbidden Signature database.
Still with me?
Here’s the problem. KB 4524244 and KB 4502496 add the old Kaspersky Rescue Disk routine to your PC’s Secure Boot Forbidden Signature database so that it is not recognized as an app approved by Microsoft. For reasons that are not at all clear, playing around with the UEFI Secure Boot restrictions has broken other programs – especially the startup routine for HP PCs with Ryzen processors. There may be other collateral damage.
Someone at Microsoft may know what happened, but I’m sure they won’t tell anyone.
What did Kaspersky do wrong?
Nothing. Except for the distribution of a Kaspersky Rescue Disk program before August 2019 that could be used for shameful purposes.
Kaspersky has detailed – and, as far as I can tell, accurate – accounting for the debacle in one newly published FAQ.
The main conclusion “Kaspersky products were not the cause of this problem”, which relates to the errors in KB 4524244, is correct. The problem lies in another conflict that was not resolved in five months of testing.
It looks like Microsoft has just tested its patch on an HP computer with a Ryzen processor. We would not be in this mess. But … Microsoft.
Microsoft has tore the patch. It is not transferred to your computer. You can’t even download it from the update catalog.
If you have KB 4524244 or KB 4502496 installed on your PC (Start> Settings> Update & Security, click on Show update history) and your computer is still working, everything is fine. The old Kaspersky Rescue Disk signature is in your Secure Boot Forbidden Signature database and you are no longer at risk of someone inserting a malicious hard drive into your computer.
If you’ve installed the update and your computer doesn’t start (another good reason) Avoid installing patches immediately, eh?), Microsoft has details on how to restore your PC to state in the KB 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 computers with the “Reset this PC” error, Microsoft also recommends that you run “Reset this PC” after uninstalling. I have no idea why uninstalling the patch and performing a reset will restore the computers to a working state, but apparently it is.
If you haven’t installed the patch yet, be in good spirits. Microsoft will find a suitable solution later. As promised by both the KB article and the release information page:
We are working with our partners on an improved version of this update and will publish it in a future update.
Let’s hope that the “improved version” works better than the old one – and that it takes less than ten months to fix the problem. Meanwhile ValdikSS warns in a tweet::
There are at least 2 other vuln bootloaders that have not been revoked.
As I can best judge, Microsoft has not released any details on this fiasco except pulling the patch, identifying the bugs, and promising a solution. Encounter security, darkness.