{"id":17779,"date":"2020-02-20T08:30:03","date_gmt":"2020-02-20T16:30:03","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2020\/02\/20\/news-11512\/"},"modified":"2020-02-20T08:30:03","modified_gmt":"2020-02-20T16:30:03","slug":"news-11512","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2020\/02\/20\/news-11512\/","title":{"rendered":"The mess behind Microsoft\u2019s yanked UEFI patch KB 4524244"},"content":{"rendered":"

<\/p>\n

Credit to Author: Woody Leonhard| Date: Thu, 20 Feb 2020 06:23:00 -0800<\/strong><\/p>\n

Remember the warning about watching how sausage is made? This is an electronic sausage-making story with lots of dirty little bits.<\/span><\/p>\n

First, the chronology. On February\u2019s Patch Tuesday, Microsoft released a bizarre standalone security patch, KB 4524244, which was then called \u201cSecurity update for Windows 10, version 1607, 1703, 1709, 1803, 1809, and 1903: Feb. 11, 2020.\u201d The name has changed, but bear with me.<\/span><\/p>\n

That patch had all sorts of weird hallmarks as I <\/span>discussed at the time<\/span><\/a>:<\/span><\/p>\n

Addresses an issue in which a third-party Unified Extensible Firmware Interface (UEFI) boot manager might expose UEFI-enabled computers to a security vulnerability.<\/span><\/p>\n

That buggy patch was accompanied by a parallel patch for older versions of Windows, <\/span>KB 4502496<\/span><\/a>, called \u201cSecurity update for Windows 10, version 1507, Windows 8.1, RT 8.1, Server 2012 R2, and Server 2012: February 11, 2020.\u201d This time the name was correct. But the Win8.1\/1507 patch <\/span>had the same bugs<\/span><\/a> and met the same fate as its more illustrious co-conspirator, KB 4524244.<\/span><\/p>\n

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\u2019t reboot normally and, when forced, the HP BIOS said it<\/span> detected an unauthorized change to the secure boot keys and had to restore<\/span><\/a>.<\/span><\/p>\n

There\u2019s a second bug in the patches, identified separately in the <\/span>Windows Release Information status<\/span><\/a> page:<\/span><\/p>\n

Using the \u201cReset this PC\u201d feature, also called \u201cPush Button Reset\u201d or PBR, might fail. You might restart into recovery with \u201cChoose an option\u201d at the top of the screen with various options or you might restart to your desktop and receive the error \u201cThere was a problem resetting your PC\u201d.<\/span><\/p>\n

The files inside the patch were dated September 2019 \u2014 five months ago. As <\/span>@abbodi86 says on AskWoody<\/span><\/a>:<\/span><\/p>\n

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.<\/span><\/p>\n

Microsoft has known about the UEFI loader security problem since April 2019, if not earlier. It took ten months to push a fix \u2014 and a buggy fix at that.<\/span><\/p>\n

So what, really, was being patched in KB 4524244? The official description then, and even now, has very little substance.<\/span><\/p>\n

It didn\u2019t take long for the <\/span>Twitterverse to point the finger<\/span><\/a> 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?<\/span><\/p>\n

That brings us to the sausage-making part of the story.<\/span><\/p>\n

Kaspersky, like other antivirus companies, includes the ability to create a boot disk \u2014 in this case, the \u201cKaspersky Rescue Disk\u201d \u2014 that\u2019ll let you boot your computer even if your PC\u2019s 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.<\/span><\/p>\n

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\u2019t been pre-approved, but this older version of the Kaspersky Rescue Disk didn\u2019t follow the Secure Boot rules.<\/span><\/p>\n

Kaspersky learned of the security hole in April 2019, plugged it on systems running Kaspersky endpoint protection, but didn\u2019t release an update to the Kaspersky Rescue Disk until August 2019.\u00a0<\/span><\/p>\n

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.<\/span><\/p>\n

If it sounds weird that Microsoft would sign a Kaspersky program \u2014 a rootkit routine, at that \u2014 it isn\u2019t. Russian blogger ValdikSS explained the conundrum in his April 2019 post “<\/span>Exploiting signed bootloaders to circumvent UEFI Secure Boot<\/span><\/a>“:<\/span><\/p>\n

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).<\/span><\/p>\n

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.<\/span><\/p>\n

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.<\/span><\/p>\n

So Microsoft did, and does, quite intentionally, sign rootkits. Er, bootkits. That way, emergency restore disks can work.\u00a0<\/span><\/p>\n

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 <\/span>UEFI Revocation List File<\/a>, which in turn updates the Secure Boot Forbidden Signature Database.\u00a0<\/span><\/p>\n

Still with me?<\/span><\/p>\n

Here\u2019s the problem. KB 4524244 and KB 4502496 add the old Kaspersky Rescue Disk routine to your PC\u2019s Secure Boot Forbidden Signature Database, so it won\u2019t be recognized as a Microsoft-approved app. But, for reasons that aren\u2019t at all clear, monkeying around with the UEFI Secure Boot restrictions broke other programs \u2014 most notably the boot routine for HP PCs with Ryzen processors. There may be other collateral damage. <\/span><\/p>\n

Somebody at Microsoft may know what went belly-up, but they certainly aren\u2019t telling anybody.<\/span><\/p>\n

Nothing. Other than distributing a Kaspersky Rescue Disk program, prior to August 2019, that could be used for nefarious purposes.\u00a0<\/span><\/p>\n

Kaspersky has a detailed \u2014 and, as far as I can tell, accurate \u2014 accounting of the debacle in a <\/span>newly released FAQ<\/span><\/a>.\u00a0<\/span><\/p>\n

The key conclusion, \u201cKaspersky products have not been a cause of this issue,\u201d referring to the bugs in KB 4524244, rings true. The problem lies in some other conflict, which went unfixed in five months of testing.<\/span><\/p>\n

It appears as if Microsoft had just tested its patch on an HP machine with a Ryzen processor we wouldn\u2019t be in this mess. But … Microsoft.<\/span><\/p>\n

Microsoft has <\/span>yanked the patch<\/span><\/a>. It won\u2019t be pushed onto your machine. You can\u2019t even download it from the Update Catalog.\u00a0<\/span><\/p>\n

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\u2019re fine. The old Kaspersky Rescue Disk signature is in your Secure Boot Forbidden Signature Database, and you\u2019re no longer at risk from someone slipping a malicious disk into your machine.<\/span><\/p>\n

If you installed the update and your machine won\u2019t boot (yet another good reason to <\/span>avoid installing patches right away<\/span><\/a>, eh?), Microsoft has details for restoring your PC to health in the <\/span>KB article<\/span><\/a> (which now mentions Win10 version 1909) and on the <\/span>Windows Release Information Status page<\/span><\/a>. The instructions tell you how to uninstall the patch. For machines with the \u201cReset this PC\u201d 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.<\/span><\/p>\n

If you haven\u2019t 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:<\/span><\/p>\n

We are working on an improved version of this update in coordination with our partners and will release it in a future update.<\/span><\/p>\n

Let\u2019s hope the \u201cimproved version\u201d works better than the old one \u2014 and that it takes less than ten months to respond to the problem. Meanwhile, ValdikSS <\/span>warns in a tweet<\/span><\/a>:<\/span><\/p>\n

At least 2 other vuln bootloaders exist, not revoked.<\/span><\/p>\n

For joy.<\/span><\/p>\n

As best I can tell, Microsoft hasn\u2019t published any details about this fiasco, other than yanking the patch, identifying the bugs and promising a fix. Security, meet obscurity.<\/span><\/p>\n

Follow the play-by-play <\/span><\/i>on AskWoody.com<\/span><\/i><\/a>.<\/span><\/i><\/p>\n

http:\/\/www.computerworld.com\/category\/security\/index.rss<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

<\/p>\n

Credit to Author: Woody Leonhard| Date: Thu, 20 Feb 2020 06:23:00 -0800<\/strong><\/p>\n

\n
\n

Remember the warning about watching how sausage is made? This is an electronic sausage-making story with lots of dirty little bits.<\/span><\/p>\n

First, the chronology. On February\u2019s Patch Tuesday, Microsoft released a bizarre standalone security patch, KB 4524244, which was then called \u201cSecurity update for Windows 10, version 1607, 1703, 1709, 1803, 1809, and 1903: Feb. 11, 2020.\u201d The name has changed, but bear with me.<\/span><\/p>\n

The original problems with KB 4524244<\/strong><\/h2>\n

That patch had all sorts of weird hallmarks as I <\/span>discussed at the time<\/span><\/a>:<\/span><\/p>\n

To read this article in full, please click here<\/a><\/p>\n<\/section>\n<\/article>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"colormag_page_container_layout":"default_layout","colormag_page_sidebar_layout":"default_layout","footnotes":""},"categories":[11062,10643],"tags":[10516,714,10525],"class_list":["post-17779","post","type-post","status-publish","format-standard","hentry","category-computerworld","category-independent","tag-microsoft","tag-security","tag-windows"],"_links":{"self":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/17779","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/comments?post=17779"}],"version-history":[{"count":0,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/17779\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/media?parent=17779"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/categories?post=17779"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/tags?post=17779"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}