Es wurden Informationen zu zwei Sicherheitsanfälligkeiten im GRUB2-Bootloader veröffentlicht, die durch die Verwendung speziell gestalteter Schriftarten und die Verarbeitung bestimmter Unicode-Zeichenfolgen zu einer Codeausführung führen können. Diese Schwachstellen können verwendet werden, um den Mechanismus der verifiziertem UEFI Secure Boot zu umgehen.
Identifizierte Schwachstellen:
- CVE-2022-2601 — Ein Buffer-Overflow in der Funktion grub_font_construct_glyph(), die bei der Verarbeitung von speziell gestalteten Schriftarten im pf2-Format auftritt. Dies geschieht aufgrund einer fehlerhaften Berechnung des Parameters max_glyph_size und der Zuweisung eines Speicherelements, das bewusst kleiner ist als erforderlich, um die Glyphen unterzubringen.
- CVE-2022-3775 — Eine Überschreibung außerhalb des zugewiesenen Speicherbereichs beim Rendern bestimmter Unicode-Sequenzen mit einer speziell gestalteten Schriftart. Das Problem besteht im Code zur Verarbeitung von Schriftarten und wird durch das Fehlen ordnungsgemäßer Überprüfungen der Übereinstimmung zwischen der Breite und Höhe der Glyphe und der vorhandenen Bitmap verursacht. Ein Angreifer kann die Eingabe so anpassen, dass eine Überzeichnung der Daten am Rand des zugewiesenen Puffers verursacht wird. Es wird angemerkt, dass trotz der Komplexität der Ausnutzung dieser Schwachstelle die Möglichkeit der Ausführung von Code nicht ausgeschlossen ist.
Die Korrektur wurde in Form eines Patches veröffentlicht. Der Status der Schwachstellenbehebung in den Distributionen kann auf den folgenden Seiten eingesehen werden: Ubuntu, SUSE, RHEL, Fedora, Debian. Um Probleme in GRUB2 zu beheben, reicht es nicht aus, das Paket einfach zu aktualisieren; es müssen außerdem neue interne digitale Signaturen erstellt und die Installer, Bootloader, Kernel-Pakete, fwupd-Firmware und die shim-Schicht aktualisiert werden.
In den meisten Linux-Distributionen wird für die verifiziertes Booten im UEFI Secure Boot-Modus eine kleine shim-Schicht verwendet, die digital von Microsoft signiert ist. Diese Schicht verifiziert GRUB2 mit ihrem eigenen Zertifikat, was es den Entwicklern der Distributionen ermöglicht, jedes Update des Kernels und von GRUB nicht bei Microsoft zu signieren. Schwachstellen in GRUB2 ermöglichen es, Code auszuführen, nachdem die shim erfolgreich verifiziert wurde, aber bevor das Betriebssystem geladen wird, indem sie sich in die Vertrauenskette während des aktiven Secure Boot-Modus einklinken und die vollständige Kontrolle über den weiteren Ladeprozess übernehmen, einschließlich des Ladens eines anderen Betriebssystems, des Modifizierens von Komponenten des Betriebssystems und des Umgehens 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 es, die Verwendung von digitalen Signaturen für bestimmte Versionen von Komponenten zu blockieren, ohne dass die Schlüssel für Secure Boot zurückgezogen werden müssen. Das Blockieren von Schwachstellen über SBAT erfordert nicht die Verwendung der UEFI-Rückrufliste (dbx), sondern erfolgt auf der Ebene des Austauschs des internen Schlüssels zur Erstellung von Signaturen und zur Aktualisierung von GRUB2, shim und anderen mitgelieferten Boot-Artefakten. Vor der Einführung von SBAT war die Aktualisierung der Rückrufliste (dbx, UEFI Revocation List) eine zwingende Voraussetzung für das vollständige Blockieren einer Schwachstelle, da ein Angreifer, unabhängig vom verwendeten Betriebssystem, ein Bootmedium mit einer alten, anfälligen Version von GRUB2, das durch eine digitale Signatur bestätigt wurde, zur Kompromittierung des UEFI Secure Boot nutzen konnte.
Quelle: opennet.ru
