{"id":99320,"date":"2021-03-03T16:22:39","date_gmt":"2021-03-03T14:22:39","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot"},"modified":"2021-03-03T16:22:39","modified_gmt":"2021-03-03T14:22:39","slug":"trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","title":{"rendered":"Hard-to-fix vulnerabilities in GRUB2 that allow bypassing UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
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. <\/p>\n
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. <\/p>\n
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. <\/p>\n
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. <\/p>\n
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. <\/p>\n
Identified vulnerabilities: <\/p>\n
\n
CVE-2020-14372 \u2014 using the acpi command in GRUB2, a privileged local system user can load modified ACPI tables by placing the SSDT (Secondary System Description Table) in the \/boot\/efi directory and altering 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, the attacker can achieve booting their kernel module or executing code through the kexec mechanism without digital signature verification.\n
CVE-2020-25632 \u2014 a use-after-free memory issue in the rmmod command implementation, which manifests when attempting to unload any module without considering its dependencies. The vulnerability does not rule out the creation of an exploit that could lead to code execution bypassing Secure Boot verification.\n
CVE-2020-25647 \u2014 a buffer overflow in the grub_usb_device_initialize() function, called during the initialization of USB devices. This issue can be exploited by connecting a specially crafted USB device that provides parameters whose size does not match the size of the buffer allocated for USB structures. An attacker can achieve the execution of code not verified in Secure Boot through manipulations with USB devices.\n
CVE-2020-27749 \u2014 a buffer overflow in the grub_parser_split_cmdline() function, which can be triggered by specifying variables larger than 1 KB in the GRUB2 command line. This vulnerability allows the execution of code bypassing Secure Boot.\n
CVE-2020-27779 \u2014 the cutmem command allows an attacker to delete a range of addresses from memory to bypass Secure Boot.\n
CVE-2021-3418 \u2014 changes in shim_lock created an additional vector for exploiting last year's vulnerability CVE-2020-15705. When installing a certificate in dbx used for signing GRUB2, GRUB2 allowed any kernel to be loaded directly without signature verification.\n
CVE-2021-20225 \u2014 the possibility of writing data beyond the buffer when executing commands with a very large number of options.\n
CVE-2021-20233 \u2014 the possibility of writing data out of bounds due to incorrect buffer size calculations when using quotes. The calculation assumed that escaping a single quote required three characters, whereas four are actually necessary. <\/ul>\n