Im Treiber, der die Arbeit mit dem NTFS-Dateisystem im GRUB2-Bootloader ermöglicht, wurde eine Sicherheitsanfälligkeit (CVE-2023-4692) entdeckt, die es ermöglicht, eigenen Code auf der Ebene des Bootloaders auszuführen, wenn auf ein speziell gestaltetes Abbild des Dateisystems zugegriffen wird. Diese Schwachstelle kann verwendet werden, um den Mechanismus des verifizierten Bootens (UEFI Secure Boot) zu umgehen.
Die Sicherheitsanfälligkeit resultiert aus einem Fehler im Code der Analyse des NTFS-Attributs „$ATTRIBUTE_LIST“ (grub-core/fs/ntfs.c), der ausgenutzt werden kann, um benutzerkontrollierte Informationen in einen Speicherbereich außerhalb des zugewiesenen Puffers zu schreiben. Bei der Verarbeitung eines speziell gestalteten NTFS-Abbildes führt ein Überlauf dazu, dass Teile des GRUB-Speichers überschrieben werden und unter bestimmten Bedingungen auch der Bereich des UEFI-Firmware-Speichers beschädigt wird, was potenziell die Ausführung eigenen Codes auf der Ebene des Bootloaders oder der Firmware ermöglicht.
Zusätzlich wurde im NTFS-Treiber von GRUB2 eine weitere Sicherheitsanfälligkeit (CVE-2023-4693) entdeckt, die es ermöglicht, den Inhalt eines beliebigen Speicherbereichs beim Parsen des Attributs „$DATA“ in einem speziell gestalteten NTFS-Image zu lesen. Unter anderem ermöglicht die Schwachstelle das Extrahieren vertraulicher, im Speicher zwischengespeicherter Daten oder das Bestimmen von Werten von EFI-Variablen.
Die Probleme wurden bisher nur durch einen Patch behoben. Den Status der Behebung von Sicherheitsanfälligkeiten in den Distributionen können Sie auf den folgenden Seiten einsehen: Debian, Ubuntu, SUSE, RHEL, 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 Installer, Bootloader, Kernel-Pakete, fwupd-Firmware und die shim-Schicht aktualisiert werden.
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 das Blockieren der Verwendung von digitalen Signaturen für bestimmte Versionen von Komponenten, ohne dass Schlüssel für den Secure Boot zurückgezogen werden müssen. Das Schließen von Sicherheitsanfälligkeiten über SBAT erfordert keine Nutzung der Liste der widerrufenen UEFI-Zertifikate (dbx), sondern erfolgt durch den Austausch des internen Schlüssels zur Erstellung von Signaturen und zur Aktualisierung von GRUB2, shim und anderen von den Distributionen bereitgestellten Boot-Artefakten. Vor der Einführung von SBAT war die Aktualisierung der Liste der widerrufenen Zertifikate (dbx, UEFI Revocation List) eine zwingende Voraussetzung für das vollständige Schließen der Sicherheitsanfälligkeit, da Angreifer unabhängig vom verwendeten Betriebssystem die UEFI Secure Boot schwächen konnten.
Quelle: opennet.ru
