Ein Patchset wurde veröffentlicht, das 6 Sicherheitsanfälligkeiten im GRUB2-Bootloader behebt, von denen die meisten zu einer Verwendung des Speichers nach seiner Freigabe (use-after-free) führen. Die potenziell identifizierten Probleme könnten genutzt werden, um den UEFI Secure Boot-Verifizierungsmechanismus 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 ist auch erforderlich, neue interne digitale Signaturen zu erstellen und die Installer, Bootloader, Kernel-Pakete, fwupd-Firmware und die shim-Schicht zu aktualisieren.
Identifizierte Schwachstellen:
- CVE-2025-61661 — Pufferüberlauf in der Funktion grub_usb_get_string(), der ausgenutzt werden kann, wenn UTF-8- und UTF-16-codierte Zeichenfolgen verarbeitet werden, die beim Anschluss von USB-Geräten übermittelt werden. Das Problem entsteht, weil der Puffer basierend auf der Größe der Zeichenfolge, die in der ersten Nachricht vom USB-Gerät angegeben ist, zugewiesen wurde, während die Größe bei der Durchführung der Codierungskonvertierung auf der Grundlage nachfolgender Lesevorgänge vom USB-Gerät berechnet wurde. So kann ein modifiziertes USB-Gerät verwendet werden, das ursprünglich einen zu niedrigen Größenwert zurückgibt.
- CVE-2025-61663, CVE-2025-61664, CVE-2025-54770, CVE-2025-61662 — fehlende Bereinigung der Befehlshandler "normal", "normal_exit", "net_set_vlan" und "gettext" beim Entladen der Module „normal“, „net“ und „gettext“, was Bedingungen schafft, die zu einem Zugriff auf den Speicher nach dessen Freigabe (use-after-free) führen können, wenn die markierten 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-Identifiers zugewiesen, da diese Befehle Teil der Testbibliothek sind und nicht in die Produktionsversionen aufgenommen werden sollten.
- CVE-2025-54771 — Fehler bei der Zählung von Verweisen auf die «fs»-Strukturen in der Funktion grub_file_close(), was zu einem Zugriff auf den Speicher nach dessen Freigabe (use-after-free) führt.
In den meisten Linux-Distributionen wird für die verifizierte Boot-Funktion im UEFI Secure Boot-Modus eine kleine Schicht namens shim verwendet, die durch ein digitales Zertifikat von Microsoft signiert ist. Diese Schicht verifiziert GRUB2 mit ihrem eigenen Zertifikat, was es den Entwicklern der Distributionen ermöglicht, nicht jedes Kernel- und GRUB-Update bei Microsoft zu signieren. Schwachstellen in GRUB2 können es ermöglichen, eigenen Code nach der erfolgreichen Verifizierung von shim, jedoch vor dem Laden des Betriebssystems auszuführen. Dabei wird die Vertrauens-Chain im aktiven Secure Boot-Modus unterbrochen, was vollständige Kontrolle über den weiteren Boot-Prozess ermöglicht, beispielsweise zum Laden eines anderen Betriebssystems, zur Modifikation von Betriebssystemkomponenten und zum Umgehen des Lockdown-Schutzes.
Um eine Schwachstelle ohne Widerruf der digitalen Signatur zu schließen, 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 in Zusammenarbeit mit Microsoft entwickelt und bedeutet, dass zusätzlich zu den ausführbaren Dateien von UEFI-Komponenten Metadaten hinzugefügt werden, die Informationen über Hersteller, Produkt, Komponente und Version enthalten. Diese Metadaten werden digital signiert und können separat in die Listen der genehmigten oder verbotenen Komponenten für UEFI Secure Boot aufgenommen werden.
SBAT ermöglicht es, die Verwendung von digitalen Signaturen für bestimmte Versionen von Komponenten zu blockieren, ohne dass die Schlüssel für Secure Boot zurückgezogen werden müssen. Das Blockieren von Schwachstellen über SBAT erfordert nicht die Verwendung der UEFI-Rückrufliste (dbx), sondern erfolgt auf der Ebene des Austauschs des internen Schlüssels zur Erstellung von Signaturen und zur Aktualisierung von GRUB2, shim und anderen mitgelieferten Boot-Artefakten. Vor der Einführung von SBAT war die Aktualisierung der Rückrufliste (dbx, UEFI Revocation List) eine zwingende Voraussetzung für das vollständige Blockieren einer Schwachstelle, da ein Angreifer, unabhängig vom verwendeten Betriebssystem, ein Bootmedium mit einer alten, anfälligen Version von GRUB2, das durch eine digitale Signatur bestätigt wurde, zur Kompromittierung des UEFI Secure Boot nutzen konnte.
Quelle: opennet.ru
