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.
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.
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.
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.
Um Probleme im Zusammenhang mit dem Verbreiten von widerrufenen Zertifikaten zu lösen, wird zukünftig der Mechanismus SBAT (UEFI Secure Boot Advanced Targeting) eingesetzt, dessen Unterstützung für GRUB2, shim und fwupd implementiert ist und der ab den nächsten Updates anstelle der Funktionen des Pakets dbxtool verwendet wird. SBAT wurde gemeinsam mit Microsoft entwickelt und sieht die Hinzufügung neuer Metadaten zu den ausführbaren Dateien der UEFI-Komponenten vor, die Informationen über Hersteller, Produkt, Komponente und Version enthalten. Die angegebenen Metadaten werden durch eine digitale Signatur verifiziert und können zusätzlich in die Listen der erlaubten oder verbotenen Komponenten für UEFI Secure Boot aufgenommen werden. Somit ermöglicht SBAT, bei einem Widerruf mit den Versionsnummern der Komponenten zu manipuliere, ohne dass Schlüssel für Secure Boot neu generiert und neue Signaturen für Kernel, shim, grub2 und fwupd erstellt werden müssen.
Festgestellte Schwachstellen:
- CVE-2020-14372 — Mithilfe des Befehls acpi in GRUB2 kann ein privilegierter Benutzer des lokalen Systems modifizierte ACPI-Tabellen laden, indem er SSDT (Secondary System Description Table) im Verzeichnis /boot/efi platziert und die Einstellungen in grub.cfg ändert. Trotz Aktivierung des Secure Boot-Modus wird das vorgeschlagene SSDT vom Kernel ausgeführt und kann verwendet werden, um den LockDown-Schutz zu deaktivieren, der die Umgehungswege für UEFI Secure Boot blockiert. Infolgedessen kann der Angreifer die Ausführung seines Kernel-Moduls oder die Ausführung von Code über den kexec-Mechanismus erreichen, ohne die digitale Signatur zu überprüfen.
- CVE-2020-25632 — Ein Zugriff auf einen bereits freigegebenen Speicherbereich (use-after-free) in der Implementierung des Befehls rmmod, der auftritt, wenn versucht wird, ein beliebiges Modul ohne Berücksichtigung der damit verbundenen Abhängigkeiten zu entladen. Die Schwachstelle schließt die Erstellung eines Exploits nicht aus, der zur Ausführung von Code führen kann, der die Validierung durch Secure Boot umgeht.
- CVE-2020-25647 — Buffer Overflow in der Funktion grub_usb_device_initialize(), die bei der Initialisierung von USB-Geräten aufgerufen wird. Das Problem kann durch den Anschluss eines speziell vorbereiteten USB-Geräts, das Parameter ausgibt, deren Größe nicht mit der für USB-Strukturen reservierten Puffergröße übereinstimmt, ausgenutzt werden. Der Angreifer kann die Ausführung von nicht im Secure Boot verifiziertem Code durch Manipulation mit USB-Geräten erreichen.
- CVE-2020-27749 — Pufferüberlauf in der Funktion grub_parser_split_cmdline(), der durch das Angeben von Variablen in der GRUB2-Befehlszeile mit einer Größe von mehr als 1 KB ausgelöst werden kann. Diese Schwachstelle ermöglicht die Ausführung von Code, der Secure Boot umgeht.
- CVE-2020-27779 — Der cutmem-Befehl ermöglicht es einem Angreifer, einen Adressbereich aus dem Speicher zu löschen, um Secure Boot zu umgehen.
- CVE-2021-3418 — Änderungen in shim_lock haben einen zusätzlichen Vektor geschaffen, um die Schwachstelle CVE-2020-15705 auszunutzen. Bei der Installation eines im dbx verwendeten Zertifikats zur Signierung von GRUB2 erlaubte GRUB2 das direkte Laden eines beliebigen Kernels ohne Signaturüberprüfung.
- CVE-2021-20225 — Möglichkeit eines Bufferüberlaufs beim Ausführen von Befehlen mit einer sehr großen Anzahl von Optionen.
- CVE-2021-20233 — Möglichkeit des Bufferüberlaufs aufgrund fehlerhafter Berechnung der Buffergöße beim Einsatz von Anführungszeichen. Bei der Berechnung der Größe wurde angenommen, dass zur Escapierung eines einfachen Anführungszeichens drei Zeichen benötigt werden, während tatsächlich vier erforderlich sind.
Quelle: opennet.ru
