Es wurden Informationen über zwei Schwachstellen im Bootloader GRUB2 bekannt, die zur Ausführung von Code führen können, wenn speziell gestaltete Schriftarten und bestimmte Unicode-Sequenzen verarbeitet werden. Diese Schwachstellen können verwendet werden, um den UEFI Secure Boot-Verifizierungsmechanismus zu umgehen.
Festgestellte Schwachstellen:
- CVE-2022-2601 — Bufferüberlauf in der Funktion grub_font_construct_glyph() bei der Verarbeitung speziell gestalteter Schriftarten im pf2-Format, verursacht durch falsche Berechnung des Parameters max_glyph_size und der Zuweisung eines Speicherbereichs, der absichtlich kleiner ist als nötig, um die Glyphen unterzubringen.
- CVE-2022-3775 — Schreibzugriff außerhalb des zugewiesenen Speicherbereichs beim Rendern bestimmter Unicode-Sequenzen mit einer speziell gestalteten Schriftart. Das Problem tritt im Schriftartenverarbeitungscode auf und wird durch fehlende Überprüfungen von Breite und Höhe der Glyphen im Verhältnis zur vorhandenen Bitmap verursacht. Ein Angreifer kann mithilfe einer spezifischen Eingabe erreichen, dass Daten über die Grenzen des zugewiesenen Puffers geschrieben werden. Es wird angemerkt, dass trotz der Komplexität der Ausnutzung der Schwachstelle die Möglichkeit der Codeausführung nicht ausgeschlossen ist.
Ein Fix wurde als Patch veröffentlicht. Der Status der Behebung der Schwachstellen in den Distributionen kann auf den folgenden Seiten eingesehen werden: Ubuntu, SUSE, RHEL, Fedora, Debian. Um die Probleme in GRUB2 zu beheben, reicht es nicht aus, nur das Paket zu aktualisieren; es müssen auch 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 verifizierte Bootfähigkeit im UEFI Secure Boot-Modus eine kleine shim-Schicht verwendet, die durch eine digitale Signatur von Microsoft signiert ist. Diese Schicht verifiziert GRUB2 mit ihrem eigenen Zertifikat, was es den Entwicklern der Distributionen ermöglicht, nicht jedes Kernel- und GRUB-Update bei Microsoft zu signieren. Schwachstellen in GRUB2 ermöglichen die Ausführung eigenen Codes nach erfolgreicher Verifizierung von shim, jedoch vor dem Laden des Betriebssystems, sodass sie sich in die Vertrauenskette während des aktiven Secure Boot-Modus einschleichen und die vollständige Kontrolle über den weiteren Bootvorgang erlangen können, einschließlich des Ladens eines anderen Betriebssystems, der Modifikation von Betriebssystemkomponenten und der Umgehung des Lockdown-Schutzes.
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 es, die Verwendung von digitalen Signaturen für bestimmte Versionsnummern von Komponenten zu blockieren, ohne dass Schlüssel für Secure Boot zurückgezogen werden müssen. Das Blockieren von Schwachstellen über SBAT erfordert nicht die Verwendung der Liste der zurückgezogenen UEFI-Zertifikate (dbx), sondern erfolgt auf der Ebene des Austauschs des inneren Schlüssels zur Erzeugung von Signaturen und zur Aktualisierung von GRUB2, shim und anderen von den Distributionen bereitgestellten Boot-Artefakten. Vor der Einführung von SBAT war das Aktualisieren der Liste der zurückgezogenen Zertifikate (dbx, UEFI Revocation List) eine Voraussetzung für die vollständige Blockierung einer Schwachstelle, da ein Angreifer, unabhängig vom verwendeten Betriebssystem, einen Boot-Medium mit einer alten, verwundbaren Version von GRUB2, die mit einer digitalen Signatur versehen war, nutzen konnte, um UEFI Secure Boot zu gefährden.
Quelle: opennet.ru
