The mess behind Microsoft’s yanked UEFI patch KB 4524244

Remember the warning about watching how sausage is made? This is an electronic sausage-making story with lots of dirty little bits.

First, the chronology. On February’s Patch Tuesday, 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: Feb. 11, 2020.” The name has changed, but bear with me.

The original problems with KB 4524244

That patch had all sorts of weird hallmarks as I discussed at the time:

• It’s a standalone security patch. We don’t get standalone security patches anymore. They’re almost invariably rolled into cumulative updates.
• It appeared to be directed at one wayward UEFI boot manager. From the KB article:

Addresses an issue in which a third-party Unified Extensible Firmware Interface (UEFI) boot manager might expose UEFI-enabled computers to a security vulnerability.

• The Knowledge Base article title was clearly wrong. Win10 version 1909 wasn’t mentioned in the KB article, but the 1909 patch appeared in the Microsoft Catalog. 

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. But the Win8.1/1507 patch had the same bugs and met the same fate as its more illustrious co-conspirator, KB 4524244.

What went awry

The patch wreaked havoc on many PCs, most notably HP PCs with Ryzen processors. 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.

There’s a second bug in the patches, identified separately in the Windows Release Information status page:

Using the “Reset this PC” feature, also called “Push Button Reset” or PBR, might fail. 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”.

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 that still was not enough to get it right.

Microsoft has known about the UEFI loader security problem since April 2019, if not earlier. It took ten months to push a fix — and a buggy fix at that.

Microsoft-authorized rootkits

So what, really, was being patched in KB 4524244? The official description then, and even now, has very little substance.

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?

That brings us to the sausage-making part of the story.

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. In order to use the Kaspersky Rescue Disk, like other recovery boot disks, you have to have physical access to the PC.

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. 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.

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. 

Compounding 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. 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.

If it sounds weird that Microsoft would sign a Kaspersky program — a rootkit routine, at that — it isn’t. Russian blogger ValdikSS explained the conundrum in his April 2019 post “Exploiting signed bootloaders to circumvent UEFI Secure Boot“:

Modern PC motherboards’ firmware follow UEFI specification since 2010. In 2013, a new technology called Secure Boot appeared, intended to prevent bootkits from being installed and run. 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).

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. It is necessary to enter UEFI settings when the computer boots, and only then it’s possible to change Secure Boot settings.

Most motherboards include only Microsoft keys as trusted, which forces bootable software vendors to ask Microsoft to sign their bootloaders. This process include code audit procedure and justification for the need to sign their file with globally trusted key if they want the disk or USB flash to work in Secure Boot mode without adding their key on each computer manually.

So Microsoft did, and does, quite intentionally, sign rootkits. Er, bootkits. That way, emergency restore disks can work. 

Revoking the UEFI signature

Microsoft can change its mind about the security clearance of its Microsoft-approved UEFI bypass programs any time, but to do so it has to add the no-longer-trusted app to something called a UEFI Revocation List File, which in turn 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 it won’t be recognized as a Microsoft-approved app. But, for reasons that aren’t at all clear, monkeying around with the UEFI Secure Boot restrictions broke other programs — most notably the boot routine for HP PCs with Ryzen processors. There may be other collateral damage.

Somebody at Microsoft may know what went belly-up, but they certainly aren’t telling anybody.

What did Kaspersky do wrong?

Nothing. Other than distributing a Kaspersky Rescue Disk program, prior to August 2019, that could be used for nefarious purposes. 

Kaspersky has a detailed — and, as far as I can tell, accurate — accounting of the debacle in a newly released FAQ. 

The key conclusion, “Kaspersky products have not been a cause of this issue,” referring to the bugs in KB 4524244, rings true. The problem lies in some other conflict, which went unfixed in five months of testing.

It appears as if Microsoft had just tested its patch on an HP machine with a Ryzen processor we wouldn’t be in this mess. But … Microsoft.

What’s next?

Microsoft has yanked the patch. It won’t be pushed onto your machine. You can’t even download it from the Update Catalog. 

If you installed KB 4524244 or KB 4502496 on your PC (Start > Settings > Update & Security, click View update history) and your machine still works, you’re fine. The old Kaspersky Rescue Disk signature is in your Secure Boot Forbidden Signature Database, and you’re no longer at risk from someone slipping a malicious disk into your machine.

If you installed the update and your machine won’t boot (yet another good reason to avoid installing patches right away, eh?), Microsoft has details for restoring your PC to health in the KB article (which now mentions Win10 version 1909) and on the Windows Release 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 uninstall with a run of Reset this PC. I have no idea why uninstalling the patch and running Reset restores machines to a working state, but apparently it does.

If you haven’t yet installed the patch, be of good cheer. Microsoft will come up with a suitable fix at some point in the future. As both the KB article and the Release 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.

Let’s hope the “improved version” works better than the old one — and that it takes less than ten months to respond to the problem. Meanwhile, ValdikSS warns in a tweet:

At least 2 other vuln bootloaders exist, not revoked.

For joy.

As best I can tell, Microsoft hasn’t published any details about this fiasco, other than yanking the patch, identifying the bugs and promising a fix. Security, meet obscurity.

Follow the play-by-play on AskWoody.com.