{"id":149133,"date":"2025-11-21T17:11:55","date_gmt":"2025-11-21T15:11:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/6-uyazvimostej-v-zagruzchike-grub2-pozvolyayushhih-obojti-uefi-secure-boot"},"modified":"2025-11-21T17:11:55","modified_gmt":"2025-11-21T15:11:55","slug":"6-uyazvimostej-v-zagruzchike-grub2-pozvolyayushhih-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/6-uyazvimostej-v-zagruzchike-grub2-pozvolyayushhih-obojti-uefi-secure-boot","title":{"rendered":"6 vulnerabilities in the GRUB2 bootloader that allow bypassing UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
A set of patches has been released to address 6 vulnerabilities in the GRUB2 bootloader, most of which lead to use-after-free memory access. The identified issues could potentially be exploited to bypass the UEFI Secure Boot verification mechanism. The status of vulnerability mitigations in distributions can be evaluated on the following pages: Debian, Ubuntu, SUSE, RHEL, Arch, and Fedora. To address the issues in GRUB2, simply updating the package is not enough; it is also necessary to generate new internal digital signatures and update installers, bootloaders, kernel packages, fwupd firmware, and the shim layer. <\/p>\n
Identified vulnerabilities: <\/p>\n
\n
CVE-2025-61661 \u2014 a buffer overflow in the function grub_usb_get_string() that can be exploited when processing strings encoded in UTF-8 and UTF-16, received during the connection of USB devices. The issue arises because the buffer was allocated based on the string size indicated in the initial message from the USB device, while the size during encoding conversion was calculated from subsequent reading operations from the USB device. Consequently, an attacker can use a modified USB device that initially returns a reduced size value.\n
CVE-2025-61663, CVE-2025-61664, CVE-2025-54770, CVE-2025-61662 \u2014 failure to clean up command handlers \u2018normal\u2019, \u2018normal_exit\u2019, \u2018net_set_vlan\u2019 and \u2018gettext\u2019 when unloading the \u2018normal\u2019, \u2018net\u2019 and \u2018gettext\u2019 modules, creating conditions for use-after-free situations when the noted commands are executed after the respective modules are unloaded. Similar vulnerabilities were also found for the commands \u2018functional_test\u2019 and \u2018all_functional_test\u2019, but they were not assigned CVE identifiers, as these commands are part of the testing library and should not be included in production builds.\n
CVE-2025-54771 \u2014 an error in the reference counting of \u2018fs\u2019 structures in the function grub_file_close(), leading to use-after-free memory access. <\/ul>\n
In most Linux distributions, a small layer called shim, signed by Microsoft, is used for verified boot in UEFI Secure Boot mode. This layer verifies GRUB2 with its own certificate, allowing distribution developers to avoid signing every kernel and GRUB update with Microsoft. Vulnerabilities in GRUB2 can lead to the execution of arbitrary code during the stage after the shim verification but before the operating system loads, thus compromising the trust chain while Secure Boot is active and gaining full control over the boot process, such as loading another OS, modifying operating system components, and bypassing Lockdown protection. <\/p>\n
To block vulnerabilities without revoking the digital signature, distributions can use the SBAT (UEFI Secure Boot Advanced Targeting) mechanism, which is supported for GRUB2, shim, and fwupd in most popular Linux distributions. SBAT was developed in collaboration with Microsoft and involves adding additional metadata to the executable files of UEFI components, including information about the manufacturer, product, component, and version. The specified metadata is digitally signed and can be separately included in lists of allowed or disallowed components for UEFI Secure Boot. <\/p>\n
SBAT allows blocking the use of digital signatures for individual version numbers of components without the need for revoking keys for Secure Boot. Blocking vulnerabilities through SBAT does not require using the UEFI revocation list (dbx) and is performed at the level of replacing the internal key for forming signatures and updating GRUB2, shim, and other boot artifacts supplied by distributions. Prior to the implementation of SBAT, updating the revocation list of certificates (dbx, UEFI Revocation List) was a prerequisite for fully blocking vulnerabilities, as an attacker, regardless of the operating system used, could compromise UEFI Secure Boot using a boot medium with an old vulnerable version of GRUB2, certified with a digital signature. \n Source: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"