Information über 21 Sicherheitsanfälligkeiten im GRUB2-Bootloader wurde veröffentlicht, von denen die meisten zu einem Pufferüberlauf führen und zum Umgehen des Validierungsmechanismus UEFI Secure Boot verwendet werden können. Die Probleme wurden bisher nur in Form eines Patches behoben. Der Status der Behebung der Sicherheitsanfälligkeiten in den Distributionen kann auf den folgenden Seiten überprüft werden: Debian, Ubuntu, SUSE, RHEL, Fedora. Um die Probleme in GRUB2 zu beheben, reicht es nicht aus, das Paket einfach 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.
Identifizierte Schwachstellen:
- CVE-2024-45774: Pufferüberlauf beim Parsen von speziell gestalteten JPEG-Bildern.
- CVE-2024-45776, CVE-2024-45777: Ganzzahlüberläufe beim Lesen von speziell gestalteten mo-Dateien, die zu einem Pufferüberlauf führen.
- CVE-2024-45778, CVE-2024-45779: Ganzzahlüberläufe beim Arbeiten mit einem beschädigten BFS-Dateisystem, die zu einem Pufferüberlauf führen.
- CVE-2024-45780: Ganzzahlüberlauf bei der Verarbeitung von speziell gestalteten tar-Archiven, der zu einem Pufferüberlauf führt.
- CVE-2024-45781, CVE-2025-0677: Pufferüberlauf bei der Arbeit mit einem beschädigten UFS-Dateisystem.
- CVE-2024-45782, CVE-2025-1125: Pufferüberlauf beim Einhängen eines speziell gestalteten HFS-Abschnitts.
- CVE-2025-0622: Zugriff auf Speicher nach dessen Freigabe bei Manipulationen mit Modulen, was zur Ausführung von Angreifer-Code führen kann.
- CVE-2025-0624: Pufferüberlauf beim Netzwerkboot.
- CVE-2025-0678: Pufferüberlauf bei der Arbeit mit einem beschädigten Squash4-Dateisystem.
- CVE-2025-0684: Pufferüberlauf bei Manipulationen mit symbolischen Links im Reiserfs-Dateisystem.
- CVE-2025-0685: Pufferüberlauf bei Manipulationen mit symbolischen Links im JFS-Dateisystem.
- CVE-2025-0685: Pufferüberlauf bei Manipulationen mit symbolischen Links im ROMFS-Dateisystem.
- CVE-2025-0689: Pufferüberlauf bei der Arbeit mit einem speziell modifizierten UDF-Abschnitt.
- CVE-2025-0690: Pufferüberlauf beim Empfang speziell gestalteter Daten von der Tastatur.
- CVE-2025-1118: Umgehung des Lockdown-Isolierungsmodus und Extraktion beliebiger Speicherinhalte durch die Ausführung des Dump-Befehls.
- CVE-2024-45775: fehlende Überprüfung des Fehlercodes beim Speichern von Speicher während der Analyse übergebener Argumente kann zu einer Beschädigung der IVT (Interrupt Vector Table) führen.
- CVE-2024-45783: Nullzeigerzugriff beim Einbinden eines fehlerhaften HFS+-Dateisystems.
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
