{"id":99320,"date":"2021-03-03T16:22:39","date_gmt":"2021-03-03T14:22:39","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot"},"modified":"2021-03-03T16:22:39","modified_gmt":"2021-03-03T14:22:39","slug":"trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","title":{"rendered":"Schwer zu beseitigende Schwachstellen in GRUB2, die es erm\u00f6glichen, UEFI Secure Boot zu umgehen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Information about 8 vulnerabilities in the GRUB2 bootloader has been revealed, allowing bypassing the UEFI Secure Boot mechanism and enabling the launch of unverified code, such as injecting malware that operates at the bootloader or kernel level. <\/p>\n

It should be noted that in most Linux distributions, a small shim layer, digitally signed by Microsoft, is used for verified booting in UEFI Secure Boot mode. This layer verifies GRUB2 with its own certificate, allowing distribution developers to avoid signing each kernel and GRUB update with Microsoft. Vulnerabilities in GRUB2 allow executing custom code after the successful verification of the shim but before the operating system boots, thus infiltrating the trust chain while Secure Boot is active and gaining full control over the subsequent boot process, including loading another OS, modifying operating system components, and bypassing Lockdown protection. <\/p>\n

As with last year's BootHole vulnerability, it is insufficient to update the bootloader to block the problem, as an attacker, regardless of the operating system used, can compromise UEFI Secure Boot by employing a boot media with an old vulnerable version of GRUB2, digitally signed. The issue can only be resolved by updating the revoked certificate list (dbx, UEFI Revocation List), but this will result in the loss of the ability to use old installation media with Linux. <\/p>\n

On systems with firmware that has updated the revoked certificate list, only updated builds of Linux distributions can be booted in UEFI Secure Boot mode. Distributions will need to update installers, bootloaders, kernel packages, fwupd firmware, and the shim layer, generating new digital signatures for them. Users will need to update installation images and other boot media and also upload the revoked certificate list (dbx) into the UEFI firmware. Until the dbx is updated in UEFI, the system remains vulnerable regardless of updates installed in the OS. The status of vulnerability remediation can be assessed on the following pages: Ubuntu, SUSE, RHEL, Debian. <\/p>\n

Um Probleme im Zusammenhang mit dem Verbreiten von widerrufenen Zertifikaten zu l\u00f6sen, wird zuk\u00fcnftig der Mechanismus SBAT (UEFI Secure Boot Advanced Targeting) eingesetzt, dessen Unterst\u00fctzung f\u00fcr GRUB2, shim und fwupd implementiert ist und der ab den n\u00e4chsten Updates anstelle der Funktionen des Pakets dbxtool verwendet wird. SBAT wurde gemeinsam mit Microsoft entwickelt und sieht die Hinzuf\u00fcgung neuer Metadaten zu den ausf\u00fchrbaren Dateien der UEFI-Komponenten vor, die Informationen \u00fcber Hersteller, Produkt, Komponente und Version enthalten. Die angegebenen Metadaten werden durch eine digitale Signatur verifiziert und k\u00f6nnen zus\u00e4tzlich in die Listen der erlaubten oder verbotenen Komponenten f\u00fcr UEFI Secure Boot aufgenommen werden. Somit erm\u00f6glicht SBAT, bei einem Widerruf mit den Versionsnummern der Komponenten zu manipuliere, ohne dass Schl\u00fcssel f\u00fcr Secure Boot neu generiert und neue Signaturen f\u00fcr Kernel, shim, grub2 und fwupd erstellt werden m\u00fcssen. <\/p>\n

Festgestellte Schwachstellen: <\/p>\n