Wenn sie ausgenutzt werden, können diese Schwachstellen Angreifern den unbefugten Zugriff auf vertrauliche Informationen ermöglichen oder allgemein Probleme verursachen
Details zu zwei Sicherheitslücken im GRUB2-Bootloader wurden bekannt, die pkönnte zur Codeausführung führen bei der Verwendung speziell entwickelter Schriftarten und beim Umgang mit bestimmten Unicode-Sequenzen.
Es wird erwähnt, dass die Schwachstellen erkannt werdene kann verwendet werden, um den von UEFI Secure Boot verifizierten Startmechanismus zu umgehen. Sicherheitslücken in GRUB2 ermöglichen die Ausführung von Code in der Phase nach der erfolgreichen Shim-Verifizierung, aber vor dem Laden des Betriebssystems, wodurch die Vertrauenskette mit aktivem Secure-Boot-Modus unterbrochen und die volle Kontrolle über den Post-Boot-Prozess erlangt wird, z. um ein anderes Betriebssystem zu starten, Betriebssystemkomponenten zu ändern und den Sperrschutz zu umgehen.
Bezüglich der identifizierten Schwachstellen wird Folgendes erwähnt:
- CVE-2022-2601: ein Pufferüberlauf in der Funktion grub_font_construct_glyph() bei der Verarbeitung von speziell präparierten Schriftarten im pf2-Format, der aufgrund einer falschen Berechnung des Parameters max_glyph_size und der Zuweisung eines Speicherbereichs auftritt, der offensichtlich kleiner ist als zum Platzieren von Glyphen benötigt wird.
- CVE-2022-3775: Schreiben außerhalb der Grenzen beim Rendern einiger Unicode-Strings in einer benutzerdefinierten Schriftart. Das Problem liegt im Code zur Schriftartbehandlung vor und wird durch einen Mangel an geeigneten Steuerelementen verursacht, um sicherzustellen, dass die Glyphenbreite und -höhe mit der verfügbaren Bitmapgröße übereinstimmen. Ein Angreifer kann Eingaben so ernten, dass eine Datenwarteschlange aus dem zugewiesenen Puffer geschrieben wird. Es wird darauf hingewiesen, dass es trotz der Komplexität der Ausnutzung der Schwachstelle nicht ausgeschlossen ist, das Problem der Codeausführung auszusetzen.
Eine vollständige Abwehr gegen alle CVEs erfordert Fixes, die mit dem neuesten SBAT aktualisiert werden (Secure Boot Advanced Targeting) und von Distributionen und Anbietern bereitgestellte Daten.
Diesmal wird die UEFI-Sperrliste (dbx) nicht verwendet und die Sperrung der kaputten
Artefakte werden nur mit SBAT hergestellt. Informationen zur Anwendung der
neuesten SBAT-Widerrufe, siehe mokutil(1). Anbieter-Fixes können explizit erlauben das Booten älterer bekannter Bootartefakte.GRUB2, Shim und andere Boot-Artefakte von allen betroffenen Anbietern werden aktualisiert. es wird verfügbar sein, wenn das Embargo aufgehoben wird oder einige Zeit danach.
Darauf wird hingewiesen Die meisten Linux-Distributionen verwenden eine kleine Patch-Schicht, von Microsoft digital signiert, für verifizierten Start im UEFI Secure Boot-Modus. Diese Schicht überprüft GRUB2 mit einem eigenen Zertifikat, die es Distributionsentwicklern ermöglicht, nicht jedes Kernel- und GRUB-Update bei Microsoft zu zertifizieren.
Um die Schwachstelle zu blockieren ohne Widerruf der digitalen Signatur, Ausschüttungen kann den SBAT-Mechanismus verwenden (UEFI Secure Boot Advanced Targeting), das von GRUB2, shim und fwupd auf den meisten gängigen Linux-Distributionen unterstützt wird.
SBAT wurde in Zusammenarbeit mit Microsoft entwickelt und umfasst das Hinzufügen zusätzlicher Metadaten zu den ausführbaren Dateien der UEFI-Komponente, einschließlich Hersteller-, Produkt-, Komponenten- und Versionsinformationen. Die angegebenen Metadaten sind digital signiert und können in separate zulässige oder verbotene Komponentenlisten für UEFI Secure Boot aufgenommen werden.
SBAT ermöglicht das Blockieren der Verwendung einer digitalen Signatur für einzelne Komponentenversionsnummern, ohne dass Schlüssel für Secure Boot widerrufen werden müssen. Das Blockieren von Schwachstellen über SBAT erfordert keine Verwendung einer UEFI-CRL (dbx), sondern erfolgt auf der internen Schlüsselersetzungsebene, um Signaturen zu generieren und GRUB2, Shim und andere von Distributionen bereitgestellte Boot-Artefakte zu aktualisieren.
Vor der Einführung von SBAT war die Aktualisierung der Zertifikatssperrliste (dbx, UEFI Revocation List) eine Voraussetzung, um die Schwachstelle vollständig zu blockieren, da ein Angreifer unabhängig vom verwendeten Betriebssystem bootfähige Medien mit einer anfälligen älteren Version von verwenden konnte GRUB2-zertifiziert durch eine digitale Signatur, um UEFI Secure Boot zu gefährden.
Schließlich Es ist erwähnenswert, dass der Fix als Patch veröffentlicht wurde., um Probleme in GRUB2 zu beheben, reicht es nicht aus, das Paket zu aktualisieren, Sie müssen auch neue interne digitale Signaturen erstellen und die Installer, Bootloader, Kernelpakete, fwupd-Firmware und Shim-Layer aktualisieren.
Der Status der Schwachstellenbehebung in Distributionen kann auf diesen Seiten bewertet werden: Ubuntu, SUSE, RHEL, Fedora y Debian.
Mehr dazu kannst du in der nachlesen folgenden Link