Grub 2: Acht neue Schwachstellen im Bootloader
Die Entwickler von Grub 2 haben mehrere Lücken gemeldet. Einige davon können erneut Secure Boot aushebeln, was den Update-Prozess deutlich verkompliziert.
- David Wolski
Für den Bootloader GNU Grub 2 steht ein ganzes Bündel an Sicherheitspatches an. Während davon einige über Paketupdates in Linux-Distributionen ausgeliefert werden, verlangt die vollständige Behebung aller acht gemeldeten Lücken erneut einen Widerruf von Signaturen in UEFI Secure Boot.
Dieser Lösungsweg klingt bekannt, schließlich war dies schon mal Mitte letztes Jahres nötig, um den Fehler "Boothole" in GNU Grub 2 zu beheben. Doch eine aktualisierte Revocation-List der anfälligen Shims für die Schlüsseldatenbank (DBX) ist problematisch, wie auch der Maintainer Daniel Kiper in seiner Meldung auf der Mailingliste betont. Teilweise ist ein Fix aller gefundenen Lücken deshalb aktuell auf einigen Systemen nicht praktikabel, denn dann würde Secure Boot gar nicht mehr funktionieren, so Kiper.
Ein langwieriges Unterfangen
Das aktuelle Update soll acht Schwachstellen beheben. Diese wurden im Zuge von Aufräumarbeiten nach "Boothole" in einer größeren Anstrengung von drei Dutzend externer Entwickler und den Maintainern des Bootloaders entdeckt. Zumindest einige der Lücken lassen sich ausnutzen, um trotz aktivem Secure Boot Kernel-Module ohne gültige Signatur nachzuladen. Eine detaillierte Beschreibung der einzelnen Lücken liefert die Ankündigung von Kiper.
Wenn man das richtig fixen will, ist es mit einem Update des fehlerhaften Codes nicht getan. Darüber hinaus müssen die Signaturen der anfälligen Versionen zumindest teilweise gesperrt werden. Das kann aber dazu führen, dass manche Systeme nicht mehr mit Secure Boot starten können.
Es gibt bereits unter anderem spezifische Advisories von Debian, von Canonical zu Ubuntu, von Red Hat und von Suse, die konkretere Informationen zum Ablauf des Update-Prozesses liefern. Alle Advisories betonen, dass die gründliche Behebung aller Lücken ein längeres Unterfangen in mehreren Schritten sein wird und eventuell auch Nacharbeit durch die Administratoren der betroffenen Systeme benötigt.
(ju)