Es wurden Informationen über 8 Schwachstellen im GRUB2-Bootloader veröffentlicht, die es Ihnen ermöglichen, den UEFI Secure Boot-Mechanismus zu umgehen und nicht überprüften Code auszuführen, beispielsweise Malware zu implementieren, die auf Bootloader- oder Kernel-Ebene ausgeführt wird.
Erinnern wir uns daran, dass in den meisten Linux-Distributionen für den verifizierten Start im UEFI Secure Boot-Modus eine kleine Shim-Schicht verwendet wird, die von Microsoft digital signiert ist. Diese Ebene verifiziert GRUB2 mit einem eigenen Zertifikat, was es Distributionsentwicklern ermöglicht, nicht jeden Kernel und jedes GRUB-Update von Microsoft zertifizieren zu lassen. Schwachstellen in GRUB2 ermöglichen es Ihnen, die Ausführung Ihres Codes bereits in der Phase nach erfolgreicher Shim-Verifizierung, jedoch vor dem Laden des Betriebssystems, zu erreichen, sich bei aktivem Secure Boot-Modus in die Vertrauenskette einzuklinken und die volle Kontrolle über den weiteren Boot-Vorgang zu erlangen, einschließlich Laden eines anderen Betriebssystems, Ändern der Betriebssystemkomponenten und Umgehen des Sperrschutzes.
Wie bei der BootHole-Schwachstelle im letzten Jahr reicht die Aktualisierung des Bootloaders nicht aus, um das Problem zu beheben, da ein Angreifer unabhängig vom verwendeten Betriebssystem bootfähige Medien mit einer alten, digital signierten, anfälligen Version von GRUB2 verwenden kann, um UEFI Secure Boot zu gefährden. Das Problem kann nur durch eine Aktualisierung der Zertifikatssperrliste (dbx, UEFI Revocation List) gelöst werden, allerdings geht in diesem Fall die Möglichkeit verloren, alte Installationsmedien mit Linux zu verwenden.
Auf Systemen mit Firmware, die über eine aktualisierte Zertifikatssperrliste verfügt, können nur aktualisierte Builds von Linux-Distributionen im UEFI Secure Boot-Modus geladen werden. Distributionen müssen Installationsprogramme, Bootloader, Kernelpakete, fwupd-Firmware und Shim-Layer aktualisieren und neue digitale Signaturen für sie generieren. Benutzer müssen Installationsimages und andere bootfähige Medien aktualisieren sowie eine Zertifikatssperrliste (dbx) in die UEFI-Firmware laden. Vor dem Update von dbx auf UEFI bleibt das System angreifbar, unabhängig von der Installation von Updates im Betriebssystem. Der Status von Schwachstellen kann auf diesen Seiten beurteilt werden: Ubuntu, SUSE, RHEL, Debian.
Um Probleme zu lösen, die bei der Verteilung widerrufener Zertifikate auftreten, ist geplant, in Zukunft den SBAT-Mechanismus (UEFI Secure Boot Advanced Targeting) zu verwenden, dessen Unterstützung für GRUB2, Shim und Fwupd implementiert wurde und ab den nächsten Updates verfügbar sein wird wird anstelle der vom dbxtool-Paket bereitgestellten Funktionalität verwendet. SBAT wurde gemeinsam mit Microsoft entwickelt und beinhaltet das Hinzufügen neuer Metadaten zu den ausführbaren Dateien von UEFI-Komponenten, die Informationen über Hersteller, Produkt, Komponente und Version enthalten. Die angegebenen Metadaten werden mit einer digitalen Signatur zertifiziert und können zusätzlich in die Listen der erlaubten oder verbotenen Komponenten für UEFI Secure Boot aufgenommen werden. Somit können Sie mit SBAT die Versionsnummern von Komponenten während des Widerrufs manipulieren, ohne Schlüssel für Secure Boot neu generieren zu müssen und ohne neue Signaturen für Kernel, Shim, grub2 und fwupd zu generieren.
Identifizierte Schwachstellen:
- CVE-2020-14372 – Mit dem acpi-Befehl in GRUB2 kann ein privilegierter Benutzer auf dem lokalen System geänderte ACPI-Tabellen laden, indem er eine SSDT (Secondary System Description Table) im Verzeichnis /boot/efi ablegt und die Einstellungen in grub.cfg ändert. Obwohl der Secure Boot-Modus aktiv ist, wird das vorgeschlagene SSDT vom Kernel ausgeführt und kann zum Deaktivieren des LockDown-Schutzes verwendet werden, der UEFI Secure Boot-Umgehungspfade blockiert. Dadurch kann ein Angreifer das Laden seines Kernelmoduls oder die Ausführung von Code über den Kexec-Mechanismus erreichen, ohne die digitale Signatur zu überprüfen.
- CVE-2020-25632 ist ein Use-After-Free-Speicherzugriff in der Implementierung des Befehls rmmod, der auftritt, wenn versucht wird, ein Modul zu entladen, ohne die damit verbundenen Abhängigkeiten zu berücksichtigen. Die Sicherheitslücke schließt die Erstellung eines Exploits nicht aus, der zur Codeausführung unter Umgehung der Secure Boot-Überprüfung führen könnte.
- CVE-2020-25647 Ein außerhalb der Grenzen liegender Schreibvorgang in der Funktion grub_usb_device_initialize(), der beim Initialisieren von USB-Geräten aufgerufen wird. Das Problem kann ausgenutzt werden, indem ein speziell vorbereitetes USB-Gerät angeschlossen wird, das Parameter erzeugt, deren Größe nicht der Größe des für USB-Strukturen zugewiesenen Puffers entspricht. Ein Angreifer kann durch Manipulation von USB-Geräten die Ausführung von Code erreichen, der nicht im Secure Boot verifiziert wird.
- CVE-2020-27749 ist ein Pufferüberlauf in der Funktion grub_parser_split_cmdline(), der durch die Angabe von Variablen größer als 2 KB in der GRUB1-Befehlszeile verursacht werden kann. Die Sicherheitslücke ermöglicht es der Codeausführung, Secure Boot zu umgehen.
- CVE-2020-27779 – Der Befehl „cutmem“ ermöglicht es einem Angreifer, einen Adressbereich aus dem Speicher zu entfernen, um Secure Boot zu umgehen.
- CVE-2021-3418 – Änderungen an shim_lock haben einen zusätzlichen Vektor geschaffen, um die letztjährige Schwachstelle CVE-2020-15705 auszunutzen. Durch die Installation des zum Signieren von GRUB2 verwendeten Zertifikats in dbx ermöglichte GRUB2 das direkte Laden jedes Kernels, ohne die Signatur zu überprüfen.
- CVE-2021-20225 – Möglichkeit des Schreibens von Daten außerhalb der Grenzen, wenn Befehle mit einer sehr großen Anzahl von Optionen ausgeführt werden.
- CVE-2021-20233 – Möglichkeit des Schreibens von Daten außerhalb der Grenzen aufgrund einer falschen Berechnung der Puffergröße bei der Verwendung von Anführungszeichen. Bei der Berechnung der Größe wurde davon ausgegangen, dass drei Zeichen erforderlich sind, um einem einfachen Anführungszeichen zu entkommen, tatsächlich waren jedoch vier erforderlich.
Source: opennet.ru