Schwer zu behebende Sicherheitsanfälligkeiten in GRUB2, die das Umgehen von UEFI Secure Boot ermöglichen.

Es wurden Informationen über 8 Schwachstellen im GRUB2-Bootloader veröffentlicht, die es ermöglichen, den UEFI Secure Boot-Mechanismus zu umgehen und nicht verifiziertem Code die Ausführung zu ermöglichen, beispielsweise durch das Einbringen von Malware, die auf der Ebene des Bootloaders oder des Kernels arbeitet.

Zur Erinnerung: In den meisten Linux-Distributionen wird zur verifiziertem Booten im UEFI Secure Boot-Modus eine kleine shim-Schicht verwendet, die durch eine digitale Signatur von Microsoft beglaubigt ist. Diese Schicht verifiziert GRUB2 mit ihrem eigenen Zertifikat, was es den Entwicklern von Distributionen ermöglicht, nicht jedes Kernel- und GRUB-Update bei Microsoft zu beglaubigen. Die Schwachstellen im GRUB2 erlauben es, eigenen Code nach der erfolgreichen Überprüfung des shims, jedoch vor dem Laden des Betriebssystems auszuführen, indem sie sich in die Vertrauenskette während des aktiven Secure Boot-Modus einfügen und die volle Kontrolle über den weiteren Bootprozess übernehmen, einschließlich des Ladens eines anderen Betriebssystems, der Modifikation von Betriebssystemkomponenten und dem Umgehen des Lockdown-Schutzes.

Ähnlich wie bei der BootHole-Sicherheitsanfälligkeit des letzten Jahres reicht es nicht aus, den Bootloader zu aktualisieren, um das Problem zu beheben. Ein Angreifer kann unabhängig vom verwendeten Betriebssystem ein bootfähiges Medium mit einer verwundbaren, älteren Version von GRUB2, die durch eine digitale Signatur verifiziert ist, verwenden, um UEFI Secure Boot zu kompromittieren. Das Problem kann nur durch ein Update der Liste der zurückgerufenen Zertifikate (dbx, UEFI Revocation List) gelöst werden, jedoch führt dies dazu, dass die Nutzung älterer Installationsmedien mit Linux nicht mehr möglich ist.

Auf Systemen mit Firmware, in denen die Liste der widerrufenen Zertifikate aktualisiert wurde, kann im UEFI Secure Boot-Modus nur mit aktualisierten Linux-Distributionen gebootet werden. Die Distributionen müssen ihre Installer, Bootloader, Kernel-Pakete, fwupd-Firmwares und die shim-Schicht aktualisieren und dafür neue digitale Signaturen erzeugen. Die Benutzer müssen die Installationsabbilder und anderen Boot-Medien aktualisieren sowie die Liste der widerrufenen Zertifikate (dbx) in die UEFI-Firmware laden. Bis die dbx in UEFI aktualisiert ist, bleibt das System unabhängig von den installierten Updates im Betriebssystem anfällig. Den Status der Behebung von Sicherheitsanfälligkeiten können Sie auf den folgenden Seiten bewerten: Ubuntu, SUSE, RHEL, Debian.

Um Probleme beim Umgang mit zurückgezogenen Zertifikaten zu lösen, 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. Dieser wird ab den nächsten Updates anstelle der Funktionen des dbxtool-Pakets verwendet. SBAT wurde in Zusammenarbeit mit Microsoft entwickelt und sieht vor, dass ausführbare Dateien von UEFI-Komponenten mit zusätzlichen Metadaten versehen werden, die Informationen über Hersteller, Produkt, Komponente und Version enthalten. Diese Metadaten werden digital signiert und können zusätzlich in Listen von erlaubten oder verbotenen Komponenten für UEFI Secure Boot aufgenommen werden. Somit ermöglicht SBAT, bei einem Rückruf die Versionsnummern von Komponenten zu manipulieren, ohne dass die Schlüssel für Secure Boot neu generiert oder neue Signaturen für Kernel, shim, grub2 und fwupd erstellt werden müssen.

Identifizierte Schwachstellen:

• CVE-2020-14372 — Mit dem Befehl acpi in GRUB2 kann ein privilegierter Benutzer des lokalen Systems modifizierte ACPI-Tabellen laden, indem er die SSDT (Secondary System Description Table) im Verzeichnis /boot/efi platziert und die Einstellungen in grub.cfg ändert. Trotz der Aktivierung des Secure Boot-Modus wird die angebotene SSDT vom Kernel ausgeführt und kann verwendet werden, um den LockDown-Schutz zu deaktivieren, der Umgehungswege des UEFI Secure Boot blockiert. Dadurch kann ein Angreifer sein Kernel-Modul laden oder Code über den kexec-Mechanismus ausführen, ohne dass eine Überprüfung der digitalen Signatur erfolgt.
• CVE-2020-25632 — Der Zugriff auf einen bereits freigegebenen Speicherbereich (use-after-free) tritt in der Implementierung des Befehls rmmod auf, was sich zeigt, wenn versucht wird, ein beliebiges Modul ohne Berücksichtigung der damit verbundenen Abhängigkeiten zu entladen. Diese Schwachstelle ermöglicht die Erstellung eines Exploits, der zur Ausführung von Code führen kann, der die Verifizierung durch Secure Boot umgeht.
• CVE-2020-25647 — Bufferüberlauf bei der Funktion grub_usb_device_initialize(), die bei der Initialisierung von USB-Geräten aufgerufen wird. Das Problem kann ausgenutzt werden, indem ein speziell präpariertes USB-Gerät angeschlossen wird, das Parameter übergibt, deren Größe nicht mit der für die USB-Strukturen reservierten Puffergröße übereinstimmt. Ein Angreifer kann die Ausführung von nicht verifiziertem Code im Secure Boot durch Manipulation von USB-Geräten erreichen.
• CVE-2020-27749 — Bufferüberlauf in der Funktion grub_parser_split_cmdline(), der durch Angabe von GRUB2-Variablen in der Befehlszeile mit einer Größe von mehr als 1 KB verursacht werden kann. Diese Schwachstelle ermöglicht es, Code zu exekutieren, ohne den Secure Boot zu umgehen.
• CVE-2020-27779 — Der Befehl cutmem ermöglicht es einem Angreifer, einen Adressbereich aus dem Speicher zu löschen, um den Secure Boot zu umgehen.
• CVE-2021-3418 — Änderungen an shim_lock haben einen zusätzlichen Vektor zur Ausnutzung der letztjährigen Schwachstelle CVE-2020-15705 geschaffen. Bei der Installation eines in dbx verwendeten Zertifikats zur Signierung von GRUB2 erlaubte GRUB2 das direkte Laden eines beliebigen Kernels ohne Signaturprüfung.
• CVE-2021-20225 — Möglichkeit, Daten über die Pufferspeicherkapazität hinaus zu schreiben, beim Ausführen von Befehlen mit einer sehr großen Anzahl von Optionen.
• CVE-2021-20233 — Möglichkeit der Datenaufzeichnung außerhalb des Puffers aufgrund einer falschen Berechnung der Puffergröße bei der Verwendung von Anführungszeichen. Bei der Berechnung der Größe wurde angenommen, dass zur Escape von einem einfachen Anführungszeichen drei Zeichen benötigt werden, obwohl tatsächlich vier notwendig sind.

Quelle: opennet.ru