Es wurden Informationen über zwei Schwachstellen im GRUB2-Bootloader veröffentlicht, die bei der Verwendung speziell entwickelter Schriftarten und der Verarbeitung bestimmter Unicode-Sequenzen zur Codeausführung führen können. Sicherheitslücken können genutzt werden, um den durch UEFI Secure Boot verifizierten Startmechanismus zu umgehen.
Identifizierte Schwachstellen:
- CVE-2022-2601 – Ein Pufferüberlauf in der Funktion grub_font_construct_glyph() bei der Verarbeitung speziell entwickelter Schriftarten im pf2-Format, der aufgrund einer falschen Berechnung des Parameters max_glyph_size und der Zuweisung eines Speicherbereichs auftritt, der offensichtlich kleiner als nötig ist Platzieren Sie die Glyphen.
- CVE-2022-3775 Beim Rendern einiger Unicode-Sequenzen in einer speziell gestalteten Schriftart kommt es zu einem Schreibvorgang außerhalb der Grenzen. Das Problem liegt im Schriftartverarbeitungscode und wird dadurch verursacht, dass keine ordnungsgemäßen Prüfungen durchgeführt wurden, um sicherzustellen, dass die Breite und Höhe des Glyphen mit der Größe der verfügbaren Bitmap übereinstimmen. Ein Angreifer kann die Eingabe so gestalten, dass das Ende der Daten außerhalb des zugewiesenen Puffers geschrieben wird. Es wird darauf hingewiesen, dass es trotz der Komplexität der Ausnutzung der Schwachstelle nicht ausgeschlossen ist, das Problem auf die Codeausführung zu übertragen.
Der Fix wurde als Patch veröffentlicht. Der Stand der Beseitigung von Schwachstellen in Distributionen kann auf diesen Seiten beurteilt werden: Ubuntu, SUSE, RHEL, Fedora, Debian. Um Probleme in GRUB2 zu beheben, reicht es nicht aus, nur das Paket zu aktualisieren; Sie müssen auch neue interne digitale Signaturen generieren und Installationsprogramme, Bootloader, Kernelpakete, fwupd-Firmware und Shim-Layer aktualisieren.
Die meisten Linux-Distributionen verwenden eine kleine, von Microsoft digital signierte Shim-Schicht für verifiziertes Booten im UEFI Secure Boot-Modus. 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.
Um die Schwachstelle zu blockieren, ohne die digitale Signatur zu widerrufen, können Distributionen den SBAT-Mechanismus (UEFI Secure Boot Advanced Targeting) verwenden, der in den meisten gängigen Linux-Distributionen für GRUB2, Shim und fwupd unterstützt wird. SBAT wurde gemeinsam mit Microsoft entwickelt und beinhaltet das Hinzufügen zusätzlicher Metadaten zu den ausführbaren Dateien von UEFI-Komponenten, darunter Informationen zu Hersteller, Produkt, Komponente und Version. Die angegebenen Metadaten werden mit einer digitalen Signatur zertifiziert und können separat in die Listen der erlaubten oder verbotenen Komponenten für UEFI Secure Boot aufgenommen werden.
Mit SBAT können Sie die Verwendung digitaler Signaturen für einzelne Komponentenversionsnummern blockieren, ohne Schlüssel für Secure Boot widerrufen zu müssen. Das Blockieren von Schwachstellen über SBAT erfordert nicht die Verwendung einer UEFI-Zertifikatsperrliste (dbx), sondern erfolgt auf der Ebene des Ersetzens des internen Schlüssels, 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 für die vollständige Blockierung der Schwachstelle, da ein Angreifer, unabhängig vom verwendeten Betriebssystem, bootfähige Medien mit einer alten anfälligen Version von GRUB2 verwenden konnte, durch eine digitale Signatur zertifiziert, um UEFI Secure Boot zu gefährden.
Source: opennet.ru