Information was disclosed about 8 vulnerabilities in the GRUB2 bootloader that allow bypassing the UEFI Secure Boot mechanism and allowing unverified code to run, for example, injecting malware that works at the bootloader or kernel level.
Recall that in most Linux distributions for verified boot in UEFI Secure Boot mode, a small shim layer is used, certified by a Microsoft digital signature. This layer verifies GRUB2 with its own certificate, which allows distribution developers not to certify every kernel and GRUB update with Microsoft. Vulnerabilities in GRUB2 allow you to execute your code at the stage after successful verification of shim, but before loading the operating system, by breaking into the chain of trust with the Secure Boot mode active and gaining full control over the further boot process, including booting another OS, modifying operating system components, and bypassing Lockdown protection.
As in the case of last year's BootHole vulnerability, updating the bootloader is not enough to block the problem, since an attacker, regardless of the operating system used, can use bootable media with an old vulnerable version of GRUB2 certified by a digital signature to compromise UEFI Secure Boot. The problem is solved only by updating the list of revoked certificates (dbx, UEFI Revocation List), but in this case, the ability to use old Linux installation media will be lost.
On systems with firmware that has an updated list of revoked certificates, only updated builds of Linux distributions will be able to boot in UEFI Secure Boot mode. Distributions will need to update installers, bootloaders, kernel packages, fwupd-firmware and shim-layer, generating new digital signatures for them. Users will need to update installation images and other bootable media, as well as upload a certificate revocation list (dbx) to the UEFI firmware. Before updating dbx to UEFI, the system remains vulnerable regardless of the installation of updates in the OS. You can check the status of the fixes on these pages: Ubuntu, SUSE, RHEL, Debian.
To solve problems that arise when distributing revoked certificates, in the future it is planned to use the SBAT (UEFI Secure Boot Advanced Targeting) mechanism, which is supported for GRUB2, shim and fwupd, and from the next updates will be used instead of the functionality provided by the dbxtool package. SBAT was developed in collaboration with Microsoft and involves adding new metadata to the UEFI component executable files, which includes information about the manufacturer, product, component, and version. The specified metadata is digitally signed and may optionally be included in the lists of allowed or prohibited components for UEFI Secure Boot. Thus, SBAT will allow manipulation of component version numbers during revocation without the need to regenerate keys for Secure Boot and without generating new signatures for the kernel, shim, grub2 and fwupd.
Identified vulnerabilities:
- CVE-2020-14372 - Using the acpi command in GRUB2, a root user of the local system can load modified ACPI tables by placing SSDT (Secondary System Description Table) in the /boot/efi directory and changing the settings in grub.cfg. Although Secure Boot mode is active, the proposed SSDT will be executed by the kernel and can be used to disable LockDown protection that blocks UEFI Secure Boot bypass paths. As a result, an attacker can achieve loading his kernel module or running code through the kexec mechanism, without verifying the digital signature.
- CVE-2020-25632 - Access to an already freed memory area (use-after-free) in the implementation of the rmmod command, which manifests itself when trying to unload any module without taking into account the dependencies associated with it. The vulnerability does not preclude the creation of an exploit that could lead to code execution bypassing Secure Boot verification.
- CVE-2020-25647 - Write out of buffer bounds in the grub_usb_device_initialize() function called when USB devices are initialized. The problem can be exploited by connecting a specially prepared USB device that emits parameters that do not match the size of the buffer allocated for USB structures. An attacker can achieve the execution of code not verified in Secure Boot by manipulating USB devices.
- CVE-2020-27749 - Buffer overflow in the grub_parser_split_cmdline() function, which can be caused by specifying variables larger than 2 KB on the GRUB1 command line. The vulnerability allows code execution to bypass 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 to shim_lock have created an additional vector for exploiting last year's CVE-2020-15705 vulnerability. By installing the certificate used to sign GRUB2 into dbx, GRUB2 allowed any kernel to be loaded directly without verifying the signature.
- CVE-2021-20225 - Ability to write data out of buffer when running commands with a very large number of options.
- CVE-2021-20233 - Ability to write data outside the buffer boundary due to incorrect calculation of the buffer size when using quotes. When calculating the size, it was assumed that three characters were required to escape a single quote, when in fact four are required.
Source: opennet.ru