{"id":90288,"date":"2020-07-30T13:42:19","date_gmt":"2020-07-30T11:42:19","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/kriticheskaya-uyazvimost-v-zagruzchike-grub2-pozvolyayushhaya-obojti-uefi-secure-boot"},"modified":"2020-07-30T13:42:19","modified_gmt":"2020-07-30T11:42:19","slug":"kriticheskaya-uyazvimost-v-zagruzchike-grub2-pozvolyayushhaya-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/kriticheskaya-uyazvimost-v-zagruzchike-grub2-pozvolyayushhaya-obojti-uefi-secure-boot","title":{"rendered":"A critical vulnerability in the GRUB2 bootloader allows bypassing UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

In the GRUB2 bootloader seven vulnerabilities have been identified<\/a><\/noindex> 8 vulnerabilities. The most dangerous issue<\/a><\/noindex> (CVE-2020-10713<\/a><\/noindex>), codenamed BootHole, allows<\/a><\/noindex> bypassing the UEFI Secure Boot mechanism and achieving the installation of unverified malware. A unique aspect of this vulnerability is that simply updating GRUB2 is insufficient, as an attacker can use a bootable medium with an old vulnerable version that is signed with a digital signature. The attacker can compromise the verification process not only for Linux but also for other operating systems, including Windows<\/a><\/noindex>. <\/p>\n

The issue is resolved only by updating the revoked certificates list<\/a><\/noindex> (dbx, UEFI Revocation List), but in this case, the ability to use old installation media with Linux will be lost. Some hardware manufacturers have already included an updated list of revoked certificates in their firmware, allowing only updated builds of Linux distributions to boot in UEFI Secure Boot mode on such systems. <\/p>\n

To eliminate the vulnerability in distributions, it is also necessary to update installers, bootloaders, kernel packages, fwupd firmware, and the shim layer by generating new digital signatures for them. Users will need to update installation images and other bootable media, as well as load the revoked certificates list (dbx) into the UEFI firmware. Until the dbx is updated in UEFI, the system remains vulnerable regardless of whether updates are installed in the OS. <\/p>\n

The vulnerability is caused by<\/a><\/noindex> buffer overflow, which can be exploited to execute arbitrary code during the boot process.
\nThe vulnerability manifests during the parsing of the grub.cfg configuration file, which is typically located in the ESP (EFI System Partition) and can be edited by an attacker with administrator rights without compromising the integrity of the signed executable files for shim and GRUB2. Due to an error<\/a><\/noindex> a coding error in the configuration parser, the fatal parsing error handler YY_FATAL_ERROR only issued a warning but did not terminate the program. The danger of the vulnerability is mitigated by the necessity of privileged access to the system; nonetheless, the issue may become relevant for implementing hidden rootkits if physical access to the hardware is available (if booting from their own medium is possible).<\/p>\n

In most Linux distributions, a small shim layer<\/a><\/noindex>, certified with a digital signature from Microsoft. This layer verifies GRUB2 with its own certificate, allowing distribution developers not to certify every kernel and GRUB update with Microsoft. The vulnerability allows for code execution after the successful verification of shim but before the operating system boots, interfering with the trust chain while Secure Boot is active and gaining full control over the subsequent boot process, including loading another OS, modifying OS components, and bypassing protections. Lockdown<\/a><\/noindex>. <\/p>\n

\"A<\/a><\/noindex><\/center><\/p>\n

Other vulnerabilities in GRUB2:<\/p>\n