Microsoft Issues Patches for 24 New Secure Boot Vulnerabilities

Secure Boot Matters

We cannot blindly trust software. The software we know and (sometimes) love today simply cannot be trusted without validation (and by software I also mean firmware). Several recent examples of supply chain breaches such as xz utils, Sisense, Rust libraries and so many more are evidence enough that software cannot be trusted. While validating software supply chains is difficult, we do have tools and techniques that can help mitigate the risk. UEFI Secure Boot is one such solution, allowing for the validation of firmware and software used in the boot process. Some will say “Secure boot is nothing more than snake oil” and others have said Secure Boot was designed by lunatics, but we simply cannot dismiss Secure Boot and other technologies that allow us to have a higher degree of trust in the software we use every day. 

All software has bugs and vulnerabilities and Secure Boot is no exception. This month, Microsoft gave us fixes for 24 new vulnerabilities in Secure Boot. That’s right, 24! I see this as a positive thing for the security community. While no software is perfect, fixing and patching is all we can do, and it’s far more dangerous not to patch something. I believe (okay, my opinion) that Microsoft is going all in on Secure Boot. They recently commissioned security researcher Bill Demerkapi to look at the security of shim, leading to the CVE-2023-40547 vulnerability discovery, and also announced upcoming updates to the Secure Boot certificates. This is all progress. For good measure, April’s Patch Tuesday not only fixed 24 Secure Boot vulnerabilities, but also addressed a Bitlocker bypass (CVE-2024-20665)  and a Lenovo UEFI vulnerability (CVE-2024-23593). 

The 24 Secure Boot vulnerabilities from April’s Patch Tuesday are listed below, along with the researchers credited with the discovery:

IDType of WeaknessMax SeverityCVSSCredit
CVE-2024-20669CWE-693: Protection Mechanism FailureImportant6.7Zammis Clark
CVE-2024-20688CWE-121: Stack-based Buffer OverflowImportant7.1Azure Yang
CVE-2024-20689CWE-121: Stack-based Buffer OverflowImportant7.1Azure Yang
CVE-2024-26168CWE-122: Heap-based Buffer OverflowImportant6.8Zammis Clark
CVE-2024-26171CWE-190: Integer Overflow or WraparoundImportant6.7Azure Yang
CVE-2024-26175 CWE-125: Out-of-bounds ReadImportant7.8Azure YangMeir Bloya (Microsoft)
CVE-2024-26180 CWE-121: Stack-based Buffer OverflowImportant8Azure Yang
CVE-2024-26189 CWE-20: Improper Input ValidationImportant8Azure Yang
CVE-2024-26194 CWE-347: Improper Verification of Cryptographic SignatureImportant7.4Microsoft
CVE-2024-26240CWE-20: Improper Input ValidationImportant8Azure Yang
CVE-2024-26250CWE-693: Protection Mechanism FailureImportant6.7Zammis Clark
CVE-2024-28896CWE-122: Heap-based Buffer OverflowImportant7.5Azure Yang
CVE-2024-28897CWE-20: Improper Input ValidationImportant6.8Azure Yang
CVE-2024-28898CWE-121: Stack-based Buffer OverflowImportant6.3Azure Yang
CVE-2024-28903 CWE-693: Protection Mechanism FailureImportant6.7Pete Batard
CVE-2024-28919CWE-693: Protection Mechanism FailureImportant6.7Zammis Clark
CVE-2024-28920CWE-693: Protection Mechanism FailureImportant7.8Anonymous
CVE-2024-28921 CWE-693: Protection Mechanism FailureImportant6.7Zammis Clark
CVE-2024-28922CWE-284: Improper Access ControlImportant4.1Zammis Clark
CVE-2024-28923CWE-190: Integer Overflow or WraparoundImportant6.4Meir Bloya (Microsoft)
CVE-2024-28924 CWE-121: Stack-based Buffer OverflowImportant6.7Zammis Clark
CVE-2024-28925CWE-121: Stack-based Buffer OverflowImportant8Azure Yang
CVE-2024-29061CWE-121: Stack-based Buffer OverflowImportant7.8Azure Yang
CVE-2024-29062CWE-367: Time-of-check Time-of-use (TOCTOU) Race ConditionImportant7.1Azure Yang

Some observations of the above vulnerabilities: 

Scope & Severity

While there may be some exceptions, all supported versions of Windows are affected by the new Secure Boot vulnerabilities. The severity ratings also vary, but keep in mind that Microsoft scored them using the CVSS, and bypassing Secure Boot requires that an attacker already have access to the system, which lowers the scores across the board. Microsoft categorizes the Secure Boot vulnerabilities as “Security Feature Bypass” which, while technically correct, doesn’t tell the whole story. Bypassing Secure Boot provides an attacker with an expanded attack surface, enabling persistence and stealth more so than many other attack vectors. And exploiting these weaknesses is possible with infected payloads: Watch this video to see a demonstration of UEFI malware evading EDR detection and bypassing Windows security features.

Eclypsium researchers have presented on Secure Boot dating as far back as 2013 at Black Hat USA in a talk titled A Tale of One Software Bypass of Windows 8 Secure Boot and again in 2014 at Defcon in Summary of Attacks Against BIOS and Secure Boot.

In July 2020 Eclypsium researchers published a vulnerability in the GRUB2 bootloader used by Linux systems dubbed Boothole, and in 2022 published research One Bootloader To Rule Them All in which more Secure Boot bypasses were disclosed, and just this year we disclosed UEFI and Secure Boot vulnerabilities on a line of rugged laptops: Protecting Rugged Gear From UEFI Threats and Secure Boot Vulnerabilities.

At this time there is no evidence that these vulnerabilities are being exploited in the wild. For all 24 of the new Secure Boot vulnerabilities, you must apply the April 9 patches in order to remediate the issues. However, you also need to take additional steps in order to fully remediate—patches alone aren’t enough in this case! Check out this KB article for step-by-step instructions. Keep in mind that if Secure Boot does halt the boot process you will need to go into the UEFI configuration (“BIOS”) and disable it until issues can be remediated. If you’ve set a BIOS password, make sure you know it and test accessing the BIOS first because if you lose access to the BIOS and Secure Boot is halting the boot process you could lock yourself out of the system and have to rebuild.

How Eclypsium Can Help

Checking The Secure Boot State: The Eclypsium supply chain security platform provides checks for Secure Boot and indicates if it is enabled/disabled and if the DBX is out-of-date. Also, attackers don’t need to bypass a feature that is already disabled! Make sure you enable Secure Boot on all systems that support it.

Vulnerabilities and Patch Deployment: Our platform identifies a number of different vulnerabilities, including several related to Secure Boot, and allows you to deploy firmware updates on select platforms. 

UEFI Threats: We also detect malicious activity in firmware and bootloaders, such as the BlackLotus UEFI malware that can take advantage of these types of vulnerabilities.

The post Microsoft Issues Patches for 24 New Secure Boot Vulnerabilities appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

Article Link: Microsoft Issues Patches for 24 New Secure Boot Vulnerabilities - Eclypsium | Supply Chain Security for the Modern Enterprise