Anders als der Name BootHole suggeriert, stecken im Linux-Boot-Manager Grub2, aber auch im Linux-Kernel, gleich mehrere Schwachstellen. Die erlauben es, Secure Boot unter Linux zu umgehen und potenziell bösartige Bootloader oder Bootkits zu laden.

Angreifer, die Rootzugang zum Bootloader eines Systems haben, können die Secure-Boot-Mechanismen von Grub2 überwinden und Bootkits oder bösartige Bootloader auf dem Rechner einschleusen, die das Betriebssystem im folgenden nicht entdeckt. Für den Cloud- und Rechenzentrumsbereich sei die Lücke laut Suse weniger gefährlich. Die Lücken wirken sich vor allem in Szenarios aus, in denen Linux-Rechner im öffentlichen Raum zum Einsatz kommen, etwa in Bibliotheken, Schulen, Universitäten, aber auch an Arbeitsplätzen.

Neben Linux-Systemen, die Grub2 verwenden (und das sind fast alle), betrifft BootHole auch indirekt Microsoft, weil das Unternehmen als UEFI Certificate Authority dient. Die Microsoft-CA stellt auch für mehrere Linux-Distributionen die Zertifikate aus, die sicherstellen, dass der von der Hardware geladene Code vertrauenswürdig ist. Dazu prüft und signiert Microsoft den Code von Drittanbietern wie Canonical oder Red Hat, der meist Shim genannt wird.

Nicht nur eine Lücke

Im Bootloader Grub2 hatte Eclypsium zunächst eine schwere Sicherheitslücke entdeckt, die beim Einlesen und Parsen der Grub-Konfiguration (“grub.cfg”) auftritt. Sie erlaubt es, einen Pufferüberlauf auszulösen und so den üblichen Secure-Boot-Verifizierungsprozess zu umgehen. Laut Canonical wurde die Lücke bereits im April 2020 im Responsible-Disclosure-Verfahren veröffentlicht, das den Distributionen Zeit gibt, sich mit Gegenmaßnahmen zu beschäftigen, bevor die Entdecker an die Öffentlichkeit gehen.

Die Entwickler der verschiedenen Linux-Distributionen haben bei dieser Gelegenheit noch einmal die Grub2-Sicherheit generell genauer unter die Lupe genommen und prompt diverse weitere Lücken in Grub2 entdeckt. Und nicht nur das: Auch der Linux-Kernel selbst erlaubt es in bestimmten Fällen, Secure Boot zu umgehen. Sämtliche Probleme listet unter anderem das von Debian veröffentlichte DSA-4735 auf. Dabei ist die Bedrohung nicht theoretisch. Eclypsium nennt mehrere bösartige Bootloader, die bereits im Umlauf sind und zum Teil von Hackergruppen im staatlichen Auftrag stammen. Einige davon sind Ransomware.

Tief verwurzelt

Ein zentrales Problem beim Reparieren dieser Lücken bestehe laut den Debian-Entwicklern darin, dass der Bootmanager ziemlich tief im System verankert ist. Es genügt nicht, neue Versionen des Bootloaders zu signieren und auszurollen. Angreifer könnten einfach weiterhin lokal ältere Versionen des Bootloaders installieren und so die Lücke wieder in Kraft setzen. Die alten Versionen gilt es also auch zu sperren. Dafür sieht UEFI Sperrlisten vor.

Das Aktualisieren solcher UEFI Revocation Lists ist allerdings heikel, weil es bei einigen Secure-Boot-Nutzern Probleme verursachen kann: Wer die Sperrliste installiert, aber weiterhin die alten Grub2-Binaries einsetzt, könnte vor einem nicht-bootbaren System sitzen. Nicht alle Nutzer bekommen es hin, Secure Boot über das UEFI-BIOS zu deaktivieren, die UEFI-Updates einzuspielen und dann das System mit Secure Boot wieder neu zu booten oder alternativ den Rescue-Modus zu verwenden. Und rollt ein unerfahrener Admin ohne zu testen gleich viele Updates aus, kann er eine ganze Armada von Systemen temporär unbenutzbar machen. Das dürfte vor allem auch den IoT-Bereich treffen, in dem Systeme weltweit ohne direkten Zugriff vor sich hin werkeln.

Dennoch will Microsoft ältere und unsichere Binaries auf eine UEFI-Revocation-Liste setzen, so dass sich diese nicht mehr verwenden lassen. Wann das aber passiert, ist laut Debian-Projekt noch unklar. Die Hardwarehersteller werden diese Listen künftig in ihre neue Firmware für neue Geräte integrieren. Linux-Distributionen liefern die Listen vermutlich über Updates aus. Die betreffen aber oft nur neuere Versionen einer Distribution. Der Grund: Debian 9 hat Secure Boot zum Beispiel noch nicht unterstützt, braucht also auch keine Updates (ist damit aber auch per se anfällig für bösartigen Bootcode).

Patches

Wie die Patches und die Strategien für die einzelnen Distributionen aussehen, unterscheidet sich je nach Anbieter. Positiv ist, dass die großen Linux-Anbieter sich offenbar gut koordinieren und ihre jeweiligen Umgehungsstrategien nahezu zeitgleich veröffentlicht haben. Hier geht es zu den jeweiligen Fehlerbeschreibungen von Debian, Ubuntu, Suse und Red Hat. Auch Microsoft liefert liefert als Aussteller der Zertifikate eine Beschreibung, um die Revocation-Liste manuell zu reparieren. Gewöhnliche Linux-Anwender sollten aber einfach die Updates für ihre Systeme einspielen.