{"id":110421,"date":"2023-10-04T09:10:18","date_gmt":"2023-10-04T07:10:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-ntfs-drajvere-iz-sostava-grub2-pozvolyayushhaya-vypolnit-kod-i-obojti-uefi-secure-boot"},"modified":"2023-10-04T09:10:18","modified_gmt":"2023-10-04T07:10:18","slug":"uyazvimost-v-ntfs-drajvere-iz-sostava-grub2-pozvolyayushhaya-vypolnit-kod-i-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/uyazvimost-v-ntfs-drajvere-iz-sostava-grub2-pozvolyayushhaya-vypolnit-kod-i-obojti-uefi-secure-boot","title":{"rendered":"Vulnerability in the NTFS driver from GRUB2 allowing code execution and bypassing UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
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. <\/p>\n
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 exploited to write user-controlled information to memory outside of the allocated buffer. When processing a specially crafted NTFS image, the overflow leads to overwriting part of GRUB's memory and, under certain conditions, can corrupt the UEFI firmware memory area, potentially allowing for the execution of custom code at the bootloader or firmware level. <\/p>\n
Additionally, another vulnerability (CVE-2023-4693) has been identified in the NTFS driver from GRUB2, which allows reading the contents of arbitrary memory areas while parsing the «$DATA» attribute in a specially crafted NTFS image. Among other things, this vulnerability enables the extraction of confidential data cached in memory or determining the values of EFI variables. <\/p>\n
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. <\/p>\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 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. \n Source: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"