CarderPlanet
Professional
A vulnerability CVE-2023-4692) has been identified in the driver that provides work with the NTFS file system in the GRUB2 loader, which allows you to organize the execution of your code at the loader level when accessing a specially designed file system image. The vulnerability can be used to bypass the UEFI Secure Boot verified boot mechanism.
The vulnerability is caused by an error in the parsing code of the NTFS attribute " $ATTRIBUTE_LIST "(grub-core/fs / ntfs. c), which can be used to write user-controlled information to a memory area outside the allocated buffer. When processing a specially designed NTFS image, an overflow causes part of GRUB's memory to be overwritten, as well as, under certain conditions, damage to the UEFI firmware's memory area, which potentially allows you to organize the execution of your code at the bootloader or firmware level.
In addition, the NTFS driver from GRUB2 also revealed another vulnerability (CVE-2023-4693), which allows you to read the contents of an arbitrary memory area when parsing the "$DATA" attribute in a specially designed NTFS image. Among other things, the vulnerability allows you to extract confidential data cached in memory, or determine the values of EFI variables.
So far, the problems have been fixed only in the form of a patch. To fix problems in GRUB2, it is not enough just to update the package; you also need to create new internal digital signatures and update installers, boot loaders,kernel packages, fwupd firmware, and the shim layer.
Most Linux distributions use a small shim layer that is digitally signed by Microsoft for verified booting in UEFI Secure Boot mode. This layer verifies GRUB2 with its own certificate, which allows distribution developers to avoid having to certify every kernel and GRUB update to Microsoft. Vulnerabilities in GRUB2 allow you to execute your code at the stage after successful shim verification, but before loading the operating system, by entering the chain of trust with Secure Boot mode active and gaining full control over the further boot process, for example, to load another OS, modify operating system components, and bypass Lockdown protection.
To block the vulnerability 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, which include information about the manufacturer, product, component, and version. The specified metadata is digitally signed and can be separately included in the lists of allowed or prohibited components for UEFI Secure Boot.
SBAT allows you to block the use of digital signatures for individual component version numbers without having to revoke keys for Secure Boot. Blocking vulnerabilities via SBAT does not require the use of a list of revoked UEFI certificates (dbx), but is performed at the level of replacing the internal key for generating signatures and updating GRUB2, shim, and other boot artifacts supplied by distributions. Before the introduction of SBAT, updating the list of revoked certificates (dbx, UEFI Revocation List) was a prerequisite for completely blocking the vulnerability, since an attacker, regardless of the operating system used, could use a bootable one to compromise UEFI Secure Boot.
The vulnerability is caused by an error in the parsing code of the NTFS attribute " $ATTRIBUTE_LIST "(grub-core/fs / ntfs. c), which can be used to write user-controlled information to a memory area outside the allocated buffer. When processing a specially designed NTFS image, an overflow causes part of GRUB's memory to be overwritten, as well as, under certain conditions, damage to the UEFI firmware's memory area, which potentially allows you to organize the execution of your code at the bootloader or firmware level.
In addition, the NTFS driver from GRUB2 also revealed another vulnerability (CVE-2023-4693), which allows you to read the contents of an arbitrary memory area when parsing the "$DATA" attribute in a specially designed NTFS image. Among other things, the vulnerability allows you to extract confidential data cached in memory, or determine the values of EFI variables.
So far, the problems have been fixed only in the form of a patch. To fix problems in GRUB2, it is not enough just to update the package; you also need to create new internal digital signatures and update installers, boot loaders,kernel packages, fwupd firmware, and the shim layer.
Most Linux distributions use a small shim layer that is digitally signed by Microsoft for verified booting in UEFI Secure Boot mode. This layer verifies GRUB2 with its own certificate, which allows distribution developers to avoid having to certify every kernel and GRUB update to Microsoft. Vulnerabilities in GRUB2 allow you to execute your code at the stage after successful shim verification, but before loading the operating system, by entering the chain of trust with Secure Boot mode active and gaining full control over the further boot process, for example, to load another OS, modify operating system components, and bypass Lockdown protection.
To block the vulnerability 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, which include information about the manufacturer, product, component, and version. The specified metadata is digitally signed and can be separately included in the lists of allowed or prohibited components for UEFI Secure Boot.
SBAT allows you to block the use of digital signatures for individual component version numbers without having to revoke keys for Secure Boot. Blocking vulnerabilities via SBAT does not require the use of a list of revoked UEFI certificates (dbx), but is performed at the level of replacing the internal key for generating signatures and updating GRUB2, shim, and other boot artifacts supplied by distributions. Before the introduction of SBAT, updating the list of revoked certificates (dbx, UEFI Revocation List) was a prerequisite for completely blocking the vulnerability, since an attacker, regardless of the operating system used, could use a bootable one to compromise UEFI Secure Boot.
