Information has been published about 21 vulnerabilities in the GRUB2 bootloader, most of which lead to buffer overflows and can be exploited to bypass the UEFI Secure Boot verification mechanism. Issues have only been addressed in the form of patches so far. The status of vulnerability remediation in the distributions can be assessed on the following pages: Debian, Ubuntu, SUSE, RHEL, Fedora. Fixing issues in GRUB2 requires not only updating the package but also generating new internal digital signatures and updating installers, bootloaders, kernel packages, fwupd firmware, and the shim layer.
Identified vulnerabilities:
- CVE-2024-45774: buffer overflow when parsing specially crafted JPEG images.
- CVE-2024-45776, CVE-2024-45777: integer overflows when reading specially crafted mo files, leading to buffer overflow.
- CVE-2024-45778, CVE-2024-45779: integer overflows when dealing with corrupted BFS file systems, leading to buffer overflow.
- CVE-2024-45780: integer overflow when processing specially crafted tar archives, leading to buffer overflow.
- CVE-2024-45781, CVE-2025-0677: buffer overflows when working with corrupted UFS file systems.
- CVE-2024-45782, CVE-2025-1125: buffer overflows when mounting specially crafted HFS partitions.
- CVE-2025-0622: use-after-free vulnerability when manipulating modules, which may lead to code execution by an attacker.
- CVE-2025-0624: buffer overflow during network booting.
- CVE-2025-0678: buffer overflows when dealing with corrupted Squash4 file systems.
- CVE-2025-0684: buffer overflows when manipulating symbolic links in Reiserfs FS.
- CVE-2025-0685: buffer overflows when manipulating symbolic links in JFS FS.
- CVE-2025-0685: buffer overflows when manipulating symbolic links in ROMFS FS.
- CVE-2025-0689: buffer overflows when working with specially modified UDF partitions.
- CVE-2025-0690: buffer overflow when receiving specially crafted data from the keyboard.
- CVE-2025-1118: bypassing Isolation Mode Lockdown and extracting arbitrary memory content through executing dump command.
- CVE-2024-45775: lack of error code checks during memory allocation when parsing passed arguments may lead to corruption of the IVT (Interrupt Vector Table).
- CVE-2024-45783: null pointer access when mounting an invalid HFS+ filesystem.
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.
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.
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.
Source: opennet.ru
