6 Sicherheitsanfälligkeiten im GRUB2-Bootloader, die das Umgehen von UEFI Secure Boot ermöglichen

Ein Patch-Set zur Behebung von 6 Schwachstellen im GRUB2-Bootloader wurde veröffentlicht, von denen die meisten zu einer Verwendung von Speicher nach dessen Freigabe (use-after-free) führen. Potenziell entdeckte Probleme könnten genutzt werden, um den Verifizierungsmechanismus der UEFI Secure Boot zu umgehen. Der Status der Behebung der Schwachstellen in den Distributionen kann auf den folgenden Seiten bewertet werden: Debian, Ubuntu, SUSE, RHEL, Arch und Fedora. Um die Probleme in GRUB2 zu beheben, reicht es nicht aus, nur das Paket zu aktualisieren; es müssen auch neue interne digitale Signaturen erstellt und die Installer, Bootloader, Kernel-Pakete, fwupd-Firmware und die shim-Schicht aktualisiert werden.

Festgestellte Schwachstellen:

• CVE-2025-61661 – Pufferüberlauf in der Funktion grub_usb_get_string(), die bei der Verarbeitung von Strings in den Codierungen UTF-8 und UTF-16, die bei der Verbindung von USB-Geräten übermittelt werden, ausgenutzt werden kann. Das Problem entsteht, weil der Puffer basierend auf der im ersten Nachrichtenpaket des USB-Geräts angegebenen Stringgröße allokiert wurde, während die Größe bei der Durchführung der Codierungsumwandlung anhand nachfolgender Lesevorgänge vom USB-Gerät berechnet wurde. Dementsprechend kann ein modifiziertes USB-Gerät für den Angriff verwendet werden, das anfangs einen zu niedrig angegebenen Größenwert zurückgibt.
• CVE-2025-61663, CVE-2025-61664, CVE-2025-54770, CVE-2025-61662 – Mangelnde Bereinigung der Command-Handler „normal“, „normal_exit“, „net_set_vlan“ und „gettext“ beim Entladen der Module „normal“, „net“ und „gettext“, was Bedingungen für die Verwendung von Speicher nach dessen Freigabe (use-after-free) schafft, wenn die genannten Befehle nach dem Entladen der entsprechenden Module ausgeführt werden. Ähnliche Schwachstellen wurden auch für die Befehle „functional_test“ und „all_functional_test“ gefunden, jedoch wurden ihnen keine CVE-Identifikatoren zugewiesen, da diese Befehle Teil der Testbibliothek sind und nicht in Produktionsversionen enthalten sein sollten.
• CVE-2025-54771 – Fehler bei der Zählung der Referenzen auf „fs“-Strukturen in der Funktion grub_file_close(), der zu einer Verwendung von Speicher nach dessen Freigabe (use-after-free) führt.

In den meisten Linux-Distributionen wird für einen verifizierten Boot im UEFI Secure Boot-Modus eine kleine Schicht namens shim verwendet, die durch eine digitale Signatur von Microsoft beglaubigt ist. Diese Schicht verifiziert GRUB2 mit ihrem eigenen Zertifikat, was es den Entwicklern der Distributionen ermöglicht, nicht jedes Update des Kernels und von GRUB bei Microsoft zu beglaubigen. Schwachstellen in GRUB2 ermöglichen das Ausführen eigenen Codes nach einer erfolgreichen Verifizierung des shim, aber vor dem Booten des Betriebssystems, indem sie sich in die Vertrauenswürdigkeit des Secure Boot-Modus einfügen und vollständige Kontrolle über den weiteren Bootprozess erhalten, zum Beispiel um ein anderes Betriebssystem zu booten, Komponenten des Betriebssystems zu modifizieren oder die Lockdown-Schutzmaßnahmen zu umgehen.

Um eine Schwachstelle zu blockieren, ohne die digitale Signatur zurückziehen zu müssen, können Distributionen den SBAT-Mechanismus (UEFI Secure Boot Advanced Targeting) verwenden, dessen Unterstützung in den meisten beliebten Linux-Distributionen für GRUB2, shim und fwupd implementiert ist. SBAT wurde gemeinsam mit Microsoft entwickelt und sieht vor, dass in die ausführbaren Dateien von UEFI-Komponenten zusätzliche Metadaten aufgenommen werden, die Informationen über Hersteller, Produkt, Komponente und Version enthalten. Diese Metadaten werden mit einer digitalen Signatur versehen und können separat in die Listen von erlaubten oder verbotenen Komponenten für UEFI Secure Boot aufgenommen werden.

SBAT ermöglicht es, die Verwendung von digitalen Signaturen für bestimmte Versionsnummern von Komponenten zu blockieren, ohne dass Schlüssel für Secure Boot zurückgezogen werden müssen. Das Blockieren von Schwachstellen über SBAT erfordert nicht die Verwendung der Liste der zurückgezogenen UEFI-Zertifikate (dbx), sondern erfolgt auf der Ebene des Austauschs des inneren Schlüssels zur Erzeugung von Signaturen und zur Aktualisierung von GRUB2, shim und anderen von den Distributionen bereitgestellten Boot-Artefakten. Vor der Einführung von SBAT war das Aktualisieren der Liste der zurückgezogenen Zertifikate (dbx, UEFI Revocation List) eine Voraussetzung für die vollständige Blockierung einer Schwachstelle, da ein Angreifer, unabhängig vom verwendeten Betriebssystem, einen Boot-Medium mit einer alten, verwundbaren Version von GRUB2, die mit einer digitalen Signatur versehen war, nutzen konnte, um UEFI Secure Boot zu gefährden.

Quelle: opennet.ru