Im Treiber, der die Arbeit mit dem NTFS-Dateisystem im Bootloader GRUB2 ermöglicht, wurde eine Schwachstelle (CVE-2023-4692) entdeckt, die die Ausführung eigenen Codes auf Bootloader-Ebene ermöglicht, wenn auf ein speziell gestaltetes Dateisystem-Image zugegriffen wird. Diese Schwachstelle kann verwendet werden, um den Mechanismus der verifiziertem UEFI Secure Boot zu umgehen.
Die Schwachstelle wird durch einen Fehler im Code der NTFS-Attribut-Analyse " $ATTRIBUTE_LIST " (grub-core/fs/ntfs.c) verursacht, die ausgenutzt werden kann, um kontrollierte Benutzerdaten in einen Speicherbereich jenseits des zugewiesenen Puffers zu schreiben. Bei der Verarbeitung eines speziell gestalteten NTFS-Images führt das Überlaufen zu einer Überschreibung eines Teils des GRUB-Speichers und in bestimmten Fällen zu einer Beschädigung des UEFI-Firmware-Speicherbereichs, was potenziell die Ausführung eigenen Codes auf Bootloader- oder Firmware-Ebene ermöglicht.
Darüber hinaus wurde im NTFS-Treiber von GRUB2 auch eine weitere Schwachstelle (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. Der Status der Behebung von Schwachstellen in den Distributionen kann auf den folgenden Seiten überprüft werden: Debian, Ubuntu, SUSE, RHEL, Fedora. Zur Behebung der Probleme in GRUB2 ist es nicht ausreichend, nur das Paket zu aktualisieren, es ist auch notwendig, neue interne digitale Signaturen zu erstellen und die Installer, Bootloader, Kernel-Pakete, fwupd-Firmware und die shim-Schicht zu aktualisieren.
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 die Blockierung der Verwendung digitaler Signaturen für einzelne Versionsnummern von Komponenten, ohne dass Schlüssel für Secure Boot zurückgerufen werden müssen. Die Blockierung von Schwachstellen durch SBAT erfordert keine Verwendung der Liste der widerrufenen UEFI-Zertifikate (dbx), sondern erfolgt auf der Ebene des Austauschs des internen Schlüssels zur Erstellung von Signaturen und zur Aktualisierung von GRUB2, shim und anderen von den Distributionen gelieferten Boot-Artefakten. Vor der Einführung von SBAT war die Aktualisierung der Liste der widerrufenen Zertifikate (dbx, UEFI Revocation List) eine obligatorische Voraussetzung für die vollständige Blockierung einer Schwachstelle, da ein Angreifer unabhängig vom verwendeten Betriebssystem den Bootloader nutzen konnte, um UEFI Secure Boot zu kompromittieren.
Quelle: opennet.ru
