A vulnerability (CVE-2023-4692) has been identified in the NTFS filesystem driver of the GRUB2 bootloader, allowing an attacker to execute arbitrary code at the bootloader level when accessing a specially crafted filesystem image. This vulnerability can be exploited to bypass the UEFI Secure Boot verified boot mechanism.
The vulnerability arises from an error in parsing the NTFS attribute "$ATTRIBUTE_LIST" (grub-core/fs/ntfs.c), which can be exploited to write user-controlled information to a memory region outside the allocated buffer. When processing a specially crafted NTFS image, the overflow results in overwriting part of GRUB's memory and, under certain conditions, can damage the UEFI firmware memory area, potentially enabling code execution at the bootloader or firmware level.
Additionally, another vulnerability (CVE-2023-4693) has been discovered in the NTFS driver of GRUB2, allowing the reading of arbitrary memory areas when parsing the "$DATA" attribute in a specially crafted NTFS image. Among other things, this vulnerability allows the extraction of sensitive data cached in memory or the determination of EFI variable values.
Currently, the issues have only been addressed in the form of patches. The status of vulnerability remediation in distributions can be assessed on the following pages: Debian, Ubuntu, SUSE, RHEL, Fedora. To resolve the issues in GRUB2, simply updating the package is insufficient; new internal digital signatures must also be created, and installers, bootloaders, kernel packages, fwupd firmware, and the shim layer need to be updated.
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 specific version numbers of components without the need to revoke keys for Secure Boot. Blocking vulnerabilities through SBAT does not require the use of the UEFI revocation certificate list (dbx), and is carried out at the internal key replacement level for signature formation and updating GRUB2, shim, and other supplied distribution boot artifacts. Before the implementation of SBAT, updating the revocation certificate list (dbx, UEFI Revocation List) was a mandatory condition for fully blocking vulnerabilities, as attackers, regardless of the operating system used, could compromise UEFI Secure Boot using bootable media.
Source: opennet.ru
