Boothole: Kein Plan, keine Sicherheit

Völlig vorhersehbare Fehler mit UEFI Secure Boot führen vermutlich noch auf Jahre zu Problemen. Vertrauen in die Technik weckt das nicht.

Ein IMHO von Sebastian Grüner veröffentlicht am 16. November 2020, 7:00 Uhr

Mit der Boothole-Lücke zeigen sich viele vorhersehbare Probleme . (Bild: puuikibeach, flickr.com/CC-BY 2.0)

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 Fehlerberichte ü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.