Background

Secure boot and its role in the validation process

Secure Boot is a UEFI firmware security feature developed by the UEFI Consortium that ensures that only immutable and signed software, that has been signed by a central authority, is loaded during the boot time. Secure Boot leverages digital signatures to validate the loaded code’s authenticity, source, and integrity. These validation steps prevent malicious code from being loaded and prevent attacks, such as the installation of certain types of rootkits.

Two databases play an important role in the validation process: The Allow DB (db) database stores the hashes and certificates for trusted loaders and EFI applications that are allowed to be loaded by the machine’s firmware. The Disallow DB (dbx) database stores revoked, compromised, and non-trusted hashes and keys. Any attempt to load signed code using the dbx keys, or in the case where the hash matches a dbx entry, will lead to boot failure.

CVE-2022-21894 and CVE-2023-24932

CVE-2022-21894 and CVE-2023-24932 are security vulnerabilities affecting Microsoft-provided binaries, utilized during the UEFI originated Windows Boot process. These vulnerabilities exploit legitimate functionality that is intended for debugging purposes to bypass the validation of Secure Boot digital signatures check.

Red Hat Enterprise Linux does not ship or use these binaries in the boot process. However, it is possible for an adequately skilled attacker with root access to orchestrate the boot process of Red Hat Enterprise Linux to misuse Microsoft-provided binaries. This would allow the attacker to bypass the firmware Secure Boot verification, install a Linux specific UEFI bootkit, and then boot into a valid Red Hat Enterprise Linux installation.

Note: Unlike the Microsoft Windows-specific UEFI bootkit, Black Lotus, Red Hat currently has no knowledge of a Linux specific bootkit that exploits CVE-2022-21894 and CVE-2023-24932 to achieve persistence.

Black Lotus

Black Lotus exploits CVE-2022-21894 and CVE-2023-24932 to achieve persistence on the system by installing a custom Machine Owner Key (MOK) without requiring physical console access. By leveraging the custom MOK installation and self-signing of bootkit binaries using this MOK, the Secure Boot process finishes without any warnings or failures.

Bootkit binaries are then run on every boot before the Operating System (OS), allowing the injection of bootkit code into core components of the OS itself. Black Lotus uses these modifications on the OS level to further hide its presence on the system to avoid detection and to provide Command & Control (C&C) functionality. Currently, the known versions of Black Lotus only target Microsoft Windows installations.

For more information about Black Lotus, refer to the BlackLotus UEFI bootkit: Myth confirmed article.

Resolution

Apply the latest dbx Revocation List update by following steps in How to update device firmware using fwupd on RHEL system. This update assures that the binaries vulnerable to CVE-2022-21894 and CVE-2023-24932 are put into the dbx, and any attempt to misuse them during the boot process would result in a failed boot.

Unlike Microsoft Windows installations, legitimate Red Hat Enterprise Linux system installations do not use the affected binaries during their boot process. Thus, there is no need to delay the updates in any way unless the system is a Microsoft Windows dual or multi- boot system. In that case, please refer to the Microsoft provided knowledge base article KB5025885: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932.