Boothole: Kein Plan, keine Sicherheit
Mit der Veröffentlichung von Windows 8 vor rund neun Jahren hat Microsoft erstmals die Secure-Boot-Technik zum Signieren und Absichern des Systemstarts vorgestellt . Die Diskussion darum und auch die Umsetzung von Secure Boot in Linux dauerten danach aber noch Jahre. Ähnlich zähe und unnötig langwierige Diskussionen und Probleme folgen nun dank der Sicherheitslücke Boothole - eine Lücke, über deren Konsequenzen vorher nicht ausreichend nachgedacht wurde, obwohl sie völlig vorhersehbar war.
Die Boothole-Lücke ermöglicht es, Code in dem Bootloader selbst auszuführen, und somit theoretisch eine volle Kontrolle darüber, welches System gestartet werden soll. Mit der Möglichkeit, dabei auch die Konfiguration selbst so zu ändern, dass Code einfach immer vor dem Start des Betriebssystems ausgeführt wird, lässt sich Schadcode dauerhaft auf einem System einschleusen.
Genau das soll Secure Boot eigentlich verhindern. Dass die Beteiligten aber offenbar überfordert damit sind, Strategien gegen eben dieses Worst-Case-Szenario umzusetzen, spricht nicht dafür, dass das System gut durchdacht wurde, und ist ein Zeichen dafür, dass selbst dieser Worst Case nicht ausreichend betrachtet wurde.
Das fängt schon damit an, dass es trotz einer sehr langen Koordinationsphase zum Veröffentlichen der Lücke und der Patches schnell verschiedene(öffnet im neuen Fenster) Fehlerberichte(öffnet im neuen Fenster) über Geräte gab, die nach Einspielen der Updates schlicht nicht mehr starteten. Das lag unter anderem an der Kombination verschiedener Versionen der Bootloader Shim und Grub.
Hier lässt sich wenigstens noch einwenden, dass hiervor mit der Veröffentlichung der Patches explizit gewarnt wurde und somit beim Einspielen entsprechend Vorsicht geboten ist. Der Fehler trat aber auch auf Systemen auf, die Secure Boot nicht aktiviert hatten oder schlicht nicht über die Funktion verfügten, da das UEFI des Rechners zu alt war. Es scheint so, als ob diese beiden Situationen schlicht nicht mit den Patches getestet wurden, bevor diese verteilt wurden. Wieso eigentlich nicht?
Bei der Secure-Boot-Technik werden Bootloader und Betriebssysteme kryptografisch signiert. Beim Start werden diese Signaturen mit Schlüsseln einer Datenbank in der Firmware des Rechners verglichen. Gelingt die Verifikation, startet auch das System selbst. Um die Lücke dauerhaft zu schließen, müssen die Signaturen zurückgezogen werden, die für die alten, verwundbaren Bootloader-Versionen genutzt wurden. Dann müssen die gepatchten Bootloader neu signiert und verteilt werden. Ebenso müssen neue Schlüssel verteilt werden, mit denen die Signaturen überprüft werden. So weit, so nachvollziehbar. Secure Boot war anfangs aber nicht außerhalb von Windows vorgesehen, was nun weitere Probleme verursacht.
Secure Boot - leichter gesagt als getan
Das System aus signierten Bootloadern und deren Überprüfung war von Microsoft zunächst ausschließlich für Windows erdacht worden, das gemeinsam mit seinen OEMs dafür gesorgt hat, dass die entsprechenden Schlüssel und signierten Bootloader verteilt werden. Damit waren aber zunächst sämtliche alternativen Betriebssysteme von Windows-Rechnern ausgeschlossen , da diese nicht über signierte Bootloader verfügten.
Microsoft machte sich dann selbst zu einer Certificate Authority (CA) für die Secure-Boot-Signaturen und signierte die alternativen Bootloader , allen voran den in Linux genutzten Shim-Loader . Nach Boothole ist Microsoft wohl aber mit der Fülle an Anfragen für neue Signaturen überfordert(öffnet im neuen Fenster) und kommt mit dem Abarbeiten nicht mehr hinterher.
Dass mit der flächendeckenden Einführung von Secure Boot in Windows andere Betriebssysteme und Hersteller von den Aktionen Microsofts abhängen, war einer der großen Kritikpunkte zur Einführung der Technik. Mit der Boothole-Lücke zeigt sich, dass diese Sorgen absolut berechtigt waren, und Microsoft hat trotzdem nichts oder einfach zu wenig dagegen unternommen.
Liste zu groß
Mehr als irritierend ist auch, dass den Verantwortlichen erst jetzt auffällt, dass der Platz für die Liste der zurückgezogenen Zertifikate und Signaturen beschränkt ist. Allein wegen Boothole müssen 3 Zertifikate und 150 Image-Hashwerte zurückgezogen werden, wie aus einem Eintrag auf Github hervor geht(öffnet im neuen Fenster) . Zusammen mit bereits vorhergehenden Ereignissen zum Zurückziehen von Signaturen sind damit bereits rund 50 Prozent der nur 32 KByte großen Datenbank belegt, die in der Firmware dafür vorgesehen ist.
Hinzu kommt, dass die Arbeiten im Zusammenhang mit Boothole noch nicht abgeschlossen sind und die Liste entsprechend weiter wachsen könnte. In dem dazu veröffentlichten Dokument heißt es außerdem, dass sich dieser Prozess wohl noch Jahre hinziehen könnte.
Offenbar hat nie jemand darüber nachgedacht, was eigentlich passiert, wenn eine Vielzahl von Signaturen und Hashes zurückgezogen werden muss, und dass die Größe der Datenbank dafür langfristig nicht ausreichen könnte. Diese Überlegungen werden erst jetzt durchgeführt, neun Jahre nach der Einführung von Secure Boot.
Bis das Datenbank-Problem gelöst ist, dürfte einiges an Zeit vergehen. Wie Heise.de berichtet(öffnet im neuen Fenster) , wird Microsoft deshalb bis mindestens Frühjahr 2021 keine weiteren alternativen Shim-Bootloader signieren. Das führt aber das gesamte Secure-Boot-System ad absurdum, da neue Boot-Medien im Zweifel eben nur noch dann starten, wenn Secure Boot deaktiviert ist.
Unternehmen ebenso wie Nutzerinnen und Nutzer müssen bei Problemen aufgrund der Boothole-Lücke also längere Zeit auf eine wichtige Sicherheitsfunktion verzichten, obwohl das Szenario eigentlich hätte betrachtet werden müssen. Das kann doch nicht wahr sein!
IMHO ist der Kommentar von Golem.de. IMHO = In My Humble Opinion (Meiner bescheidenen Meinung nach) .