{"id":104320,"date":"2022-06-08T15:36:43","date_gmt":"2022-06-08T13:36:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot"},"modified":"2022-06-08T15:36:43","modified_gmt":"2022-06-08T13:36:43","slug":"uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","title":{"rendered":"Vulnerabilities in GRUB2 allow bypassing UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
The GRUB2 bootloader has addressed 7 vulnerabilities allowing circumvention of the UEFI Secure Boot mechanism, enabling the execution of unverified code, such as the injection of malware that operates at the bootloader or kernel level. Additionally, one vulnerability in the shim layer has also been noted, which allows bypassing UEFI Secure Boot. This group of vulnerabilities has been codenamed Boothole 3, similar to previously identified issues in the bootloader. <\/p>\n
To address issues in GRUB2 and shim, distributions will be able to utilize the SBAT (UEFI Secure Boot Advanced Targeting) mechanism, which is supported for GRUB2, shim, and fwupd. SBAT was developed in collaboration with Microsoft and involves adding additional metadata to the executable files of UEFI components, which includes information about the manufacturer, product, component, and version. This metadata is digitally signed and can be separately included in the lists of allowed or disallowed components for UEFI Secure Boot. <\/p>\n
In most Linux distributions, a small shim layer, digitally signed by Microsoft, is used for verified boot in UEFI Secure Boot mode. This shim verifies GRUB2 with its own certificate, allowing distribution developers to avoid signing each kernel and GRUB update with Microsoft. Vulnerabilities in GRUB2 can enable code execution after the successful verification of the shim but before the operating system boots, intruding into the trust chain during active Secure Boot mode and gaining full control of the boot process, including the ability to load another OS, modify OS components, and bypass Lockdown protection. <\/p>\n
To resolve the issues in the bootloader, distributions will have to create new internal digital signatures and update installers, bootloaders, kernel packages, fwupd firmware, and the shim layer. Prior to the implementation of SBAT, updating the revoked certificate list (dbx, UEFI Revocation List) was a mandatory condition for the complete blocking of the vulnerability, as an attacker, regardless of the operating system used, could compromise UEFI Secure Boot by using a bootable media with an old vulnerable version of GRUB2, signed with a digital signature. <\/p>\n
Instead of revoking signatures, SBAT allows blocking their use for specific component version numbers without the need to revoke keys for Secure Boot. Blocking vulnerabilities through SBAT does not require the use of the UEFI revoked certificate list (dbx), and is carried out at the level of replacing the internal key for signature generation and updating GRUB2, shim, and other boot artifacts provided by distributions. Currently, SBAT support has already been added to most popular Linux distributions. <\/p>\n
Identified vulnerabilities: <\/p>\n
\n
CVE-2021-3696, CVE-2021-3695 - buffer overflow in heap when processing specially crafted PNG images, which could theoretically be exploited to execute attacker code and bypass UEFI Secure Boot. It is noted that the issue is difficult to exploit, as creating a working exploit requires accounting for a large number of factors and knowledge of memory layout.\n
CVE-2021-3697 - buffer underflow in JPEG image processing code. Exploiting this issue requires knowledge of memory layout and is about as complex as the PNG issue (CVSS 7.5).\n
CVE-2022-28733 \u2014 an integer overflow in the grub_net_recv_ip4_packets() function, allowing manipulation of the rsm->total_len parameter through the sending of a specially crafted IP packet. This issue has been marked as the most dangerous among the vulnerabilities presented (CVSS 8.1). Successful exploitation of the vulnerability allows for writing data beyond the buffer through the allocation of a deliberately smaller size of memory.\n
CVE-2022-28734 \u2014 a one-byte buffer overflow when processing split HTTP headers. This issue may lead to corruption of GRUB2 metadata (writing a null byte immediately after the end of the buffer) when parsing specially crafted HTTP requests.\n
CVE-2022-28735 \u2014 a problem in the shim_lock verifier, allowing the loading of files unrelated to the kernel. The vulnerability can be exploited to load unsigned kernel modules or unverified code in UEFI Secure Boot mode.\n
CVE-2022-28736 \u2014 access to already freed memory in the grub_cmd_chainloader() function through the re-execution of the chainloader command used to boot operating systems not supported in GRUB2. Exploitation may lead to the execution of attacker's code if the attacker can determine the memory allocation patterns in GRUB2.\n
CVE-2022-28737 \u2014 a buffer overflow in the shim layer, occurring in the handle_image() function when loading and executing specially crafted EFI images. <\/ul>\n