Details have emerged regarding 8 vulnerabilities in the GRUB2 bootloader that allow bypassing the UEFI Secure Boot mechanism, enabling the execution of unverified code, such as the injection of malware operating at the bootloader or kernel level.
It's worth noting that in most Linux distributions, a small shim layer, digitally signed by Microsoft, is used for verified booting in UEFI Secure Boot mode. This shim verifies GRUB2 with its own certificate, allowing distribution developers not to sign every kernel and GRUB update through Microsoft. The vulnerabilities in GRUB2 can lead to the execution of arbitrary code after the successful verification of shim but before the operating system boots, compromising the trust chain while Secure Boot is active and gaining full control over the boot process, including loading other operating systems, modifying operating system components, and bypassing Lockdown protection.
As with last year's BootHole vulnerability, simply updating the bootloader is not enough to prevent the issue, as an attacker can use a bootable medium with an older vulnerable version of GRUB2, signed with a digital signature, regardless of the operating system. The problem can only be resolved by updating the revoked certificates list (dbx, UEFI Revocation List), but this would result in losing the ability to use older Linux installation media.
On systems with firmware that has updated the list of revoked certificates, only updated builds of Linux distributions can be booted in UEFI Secure Boot mode. Distributions will need to update installers, bootloaders, kernel packages, fwupd firmware, and the shim layer, generating new digital signatures for them. Users will have to update installation images and other boot media and also load the revoked certificates list (dbx) into the UEFI firmware. Until the dbx is updated in UEFI, the system remains vulnerable regardless of updates installed in the OS. The status of vulnerability remediation can be assessed on the following pages: Ubuntu, SUSE, RHEL, Debian.
To address issues arising from the distribution of revoked certificates, a mechanism called SBAT (UEFI Secure Boot Advanced Targeting) is planned for future implementation. Support for this mechanism has been incorporated into GRUB2, shim, and fwupd, and it will be utilized in the upcoming updates instead of the functionality provided by the dbxtool package. SBAT has been developed in collaboration with Microsoft and involves adding new metadata to UEFI component executables that includes information about the manufacturer, product, component, and version. This metadata is digitally signed and can additionally be included in lists of allowed or prohibited components for UEFI Secure Boot. Thus, SBAT will allow manipulation of component version numbers upon revocation without the need to re-generate keys for Secure Boot and without forming new signatures for the kernel, shim, grub2, and fwupd.
Identified vulnerabilities:
- CVE-2020-14372 — Using the acpi command in GRUB2, a privileged user on the local system can load modified ACPI tables by placing an SSDT (Secondary System Description Table) in the /boot/efi directory and modifying settings in grub.cfg. Despite Secure Boot being active, the proposed SSDT will be executed by the kernel and can be used to disable LockDown protection, which blocks UEFI Secure Boot bypass paths. As a result, an attacker may load their kernel module or execute code through the kexec mechanism without digital signature verification.
- CVE-2020-25632 — A use-after-free vulnerability in the rmmod command implementation, manifesting when attempting to unload a module without considering its dependencies. This vulnerability does not rule out the creation of an exploit that could lead to code execution bypassing Secure Boot verification.
- CVE-2020-25647 — A buffer overflow in the grub_usb_device_initialize() function, which is called during the initialization of USB devices. The issue can be exploited by connecting a specially crafted USB device that reports parameters whose size does not match the size of the allocated buffer for USB structures. An attacker may achieve the execution of unverified code in Secure Boot through manipulation of USB devices.
- CVE-2020-27749 — a buffer overflow in the function grub_parser_split_cmdline(), which can be triggered by specifying more than 1 KB of variables in the GRUB2 command line. This vulnerability allows for code execution bypassing Secure Boot.
- CVE-2020-27779 — the cutmem command allows an attacker to remove a range of addresses from memory to bypass Secure Boot.
- CVE-2021-3418 — changes in shim_lock created an additional vector for exploiting last year's CVE-2020-15705 vulnerability. When a certificate used for signing GRUB2 is installed in dbx, GRUB2 allowed the loading of any kernel directly without signature verification.
- CVE-2021-20225 — the possibility of writing data outside the buffer when executing commands with a very large number of options.
- CVE-2021-20233 — the possibility of writing data beyond the buffer due to an incorrect calculation of the buffer size when using quotes. The calculation assumed that escaping a single quote required three characters, while in fact, four are necessary.
Source: opennet.ru
