Es wurden Informationen über 21 Sicherheitsanfälligkeiten im GRUB2-Bootloader veröffentlicht, von denen die meisten zu Pufferüberläufen führen und zur Umgehung des UEFI Secure Boot-Validierungsmechanismus verwendet werden können. Die Probleme wurden bisher nur in Form von Patches behoben. Der Status der Behebung von Sicherheitsanfälligkeiten in verschiedenen Distributionen kann auf diesen Seiten eingesehen werden: Debian, Ubuntu, SUSE, RHEL, Fedora. Um die Probleme im GRUB2 zu beheben, reicht es nicht aus, nur das Paket zu aktualisieren; es müssen auch neue interne digitale Signaturen erstellt und Installer, Bootloader, Kernel-Pakete, fwupd-Firmware und die shim-Umgebung aktualisiert werden.
Festgestellte Schwachstellen:
- CVE-2024-45774: Pufferüberlauf bei der Verarbeitung von speziell gestalteten JPEG-Bildern.
- CVE-2024-45776, CVE-2024-45777: Ganzzahlüberläufe beim Lesen speziell gestalteter mo-Dateien, die zu einem Pufferüberlauf führen.
- CVE-2024-45778, CVE-2024-45779: Ganzzahlüberläufe beim Arbeiten mit beschädigten BFS-Dateisystemen, die zu Pufferüberläufen führen.
- CVE-2024-45780: Ganzzahlüberlauf bei der Verarbeitung speziell gestalteter tar-Archive, der zu einem Pufferüberlauf führt.
- CVE-2024-45781, CVE-2025-0677: Pufferüberläufe beim Arbeiten mit beschädigten UFS-Dateisystemen.
- CVE-2024-45782, CVE-2025-1125: Pufferüberläufe beim Einbinden eines speziell gestalteten HFS-Partitions.
- CVE-2025-0622: Zugriff auf Speicher nach dessen Freigabe bei der Manipulation mit Modulen, was zur Ausführung von Angreifer-Code führen kann.
- CVE-2025-0624: Pufferüberlauf beim Netzwerkboot.
- CVE-2025-0678: Pufferüberläufe beim Arbeiten mit beschädigten Squash4-Dateisystemen.
- CVE-2025-0684: Pufferüberläufe bei der Manipulation von symbolischen Links im Reiserfs-Dateisystem.
- CVE-2025-0685: Pufferüberläufe bei der Manipulation von symbolischen Links im JFS-Dateisystem.
- CVE-2025-0685: Pufferüberläufe bei der Manipulation von symbolischen Links im ROMFS-Dateisystem.
- CVE-2025-0689: Pufferüberläufe beim Arbeiten mit einem speziell modifizierten UDF-Partition.
- CVE-2025-0690: Pufferüberläufe beim Erfassen speziell gestalteter Tastaturdaten.
- CVE-2025-1118: Umgehung des Lockdown-Isolationsmodus und Extraktion beliebiger Inhalte aus dem Speicher durch Ausführen des Befehls dump.
- CVE-2024-45775: Fehlende Fehlercode-Prüfung bei der Speicherzuweisung bei der Verarbeitung übergebener Argumente kann zu Datenbeschädigungen der IVT (Interrupt Vector Table) führen.
- CVE-2024-45783: Zugriff über einen Nullzeiger beim Einbinden eines fehlerhaften HFS+-Dateisystems.
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
