[English]Microsoft has released a new Servicing Stack Update (SSU) for Windows 10. The SSU KB5001205 is supposed to fix a vulnerability in the fixt Security Boot. This vulnerability was torn open by a previous update for the Security Boot.
Yesterday I had reported in the blog post Windows 10 1809/1909: Preview Updates (March 25, 2021) about preview updates for Windows 10. The preview update is supposed to fix a number of issues and remove the old Edge browser from the Windows 10 version 1909 in question.
New SSU KB5001205 for Windows 10 Version 1909
Service Stack Update (SSU) KB5001205 has also been mentioned for Windows 10 version 1909, and Microsoft strongly recommends installing it. I now took a closer look at the description of this SSU , which was released for the Intel and ARM versions of Windows 10 version 1909 and Windows Server version 1909 (Server Core installation). The support article states.
This update makes quality improvements to the servicing stack, which is the component that installs Windows updates. Servicing stack updates (SSU) makes sure that you have a robust and reliable servicing stack so that your devices can receive and install Microsoft updates.
This is nothing new, as improving the quality and stability of the servicing stack and Windows Update is always the goal of the now probably monthly SSUs. But there is another addition that targets a security boot vulnerability.
This update also addresses an issue that might prevent the CVE-2020-0689 update from installing. The error message in the CBS.log file is TRUST_E_NOSIGNATURE. To learn more about this security vulnerability, see CVE-2020-0689 | Microsoft Secure Boot Security Feature Bypass Vulnerability.
There, the reader learns that the SSU also fixes a problem that prevents the update for CVE-2020-0689 from being installed. Microsoft doesn't give any further details there.
The TRUST_E_NOSIGNATURE error (error code 0x800b0100) probably signals that no valid signature was found in the package. Since the SSU was only released for Windows 10 V1909, it does not seem to have been a problem with the update, but a problem with the servicing stack in Windows Update.
This SSU update is offered via Windows Update on appropriate systems, but can also be downloaded via Microsoft Update Catalog as a package and then installed manually. In addition, Microsoft offers this update in WSUS for distribution to affected machines, they probably attach a high importance to the problem.
The background of the vulnerability
In January 2021, there was security update KB4535680 (Security update for Secure Boot DBX: January 12, 2021), which I covered in the blog post Windows Security Update KB4535680 for Secure Boot (DBX). Windows devices with UEFI (Unified Extensible Firmware Interface)-based firmware had a vulnerability that allows bypassing security features in Secure Boot (see CVE-2020-0689 | Microsoft Secure Boot Security Feature Bypass Vulnerability). The Secure Boot Forbidden Signature Database (DBX) could not prevent UEFI modules from loading. An attacker who successfully exploited this vulnerability could bypass Secure Boot and load untrusted software. Security update KB4535680 (Security update for Secure Boot DBX: January 12, 2021) made improvements to Secure Boot DBX for supported Windows versions in this regard by adding new modules to DBX. The security update was rolled out for Windows 8.1/Server 2012/R2 through Windows 10 version 1909 and its server counterparts.
Issues with Bitlocker systems
Update KB4535680 has also another issue beside the error message TRUST_E_NOSIGNATURE left in the CBS.log. Searching this blog, I found the article Windows 10: KB4535680 may trigger a Bitlocker Recovery. There I had reported that this update triggered a Bitlocker recovery on various Windows 10 devices after installation. Especially HP devices seem to be affected – but also Surface Laptop 1/2 was mentioned. Was anyone affected by this issue and is it fixed by the SSU? (via)
Similar articles
Windows Security Update KB4535680 for Secure Boot (DBX)
Windows 10: KB4535680 may trigger a Bitlocker Recovery