Matthew Garrett, ein bekannter Linux-Kernel-Entwickler, der einst vom SPI-Stiftung für seinen Beitrag zur Entwicklung von Open Source Software ausgezeichnet wurde, sprach über die Funktionsweise des SBAT (Secure Boot Advanced Targeting) Mechanismus, der entwickelt wurde, um Schwachstellen im Bootloader ohne Widerruf von digitalen Signaturen zu blockieren, sowie über seine Rolle in dem kürzlichen Vorfall mit einem Windows-Update, das dazu führte, dass einige Linux-Distributionen, die parallel zu Windows auf Systemen mit aktiviertem UEFI Secure Boot installiert waren, nicht mehr booten konnten. Kurz gesagt, dafür sind sowohl die Firma Microsoft verantwortlich, die das Update nicht umfassend getestet und auf Systeme angewendet hat, auf die es nicht angewendet werden sollte, als auch die Entwickler einiger Linux-Distributionen, die den GRUB-Bootloader und die SBAT-Generation nicht aktualisiert haben, als Schwachstellen im GRUB entdeckt wurden.
Nachfolgend die Übersetzung der Notiz von Garrett:
Als die Spezifikation für UEFI Secure Boot entwickelt wurde, waren alle Beteiligten, sagen wir, etwas naiv. Das Hauptsicherheitsmodell von Secure Boot besagt, dass aller Code, der in einer privilegierten Umgebung auf Kernel-Ebene ausgeführt wird, vor der Ausführung überprüft werden muss – die Firmware überprüft den Bootloader, der Bootloader überprüft den Kernel, der Kernel überprüft jeden zusätzlichen zur Laufzeit geladenen Kernel-Code, und nun haben wir eine vertrauenswürdige Umgebung, um jede andere Sicherheitsrichtlinie, die wir wollen, durchzusetzen. Offensichtlich können Menschen Fehler machen, aber in der Spezifikation wurde ein Verfahren zum Widerruf von signierten Komponenten vorgesehen, die sich als nicht vertrauenswürdig erwiesen: Einfach den Hash des unbeaufsichtigten Codes in eine Variable einfügen und dann die Ausführung von allem mit diesem Hash verweigern, selbst wenn es mit einem vertrauenswürdigen Schlüssel signiert ist.
Leider hat sich herausgestellt, dass das Problem im Maßstab liegt. Jede Linux-Distribution, die im Secure-Boot-Ökosystem arbeitet, erzeugt ihre eigenen Binärdateien des Bootloaders, und jede von ihnen hat ihren eigenen Hash. Wenn im Quellcode eines solchen Bootloaders eine Verwundbarkeit entdeckt wird, müssen eine Vielzahl unterschiedlicher Binärdateien zurückgerufen werden. Der Speicherplatz für die Speicherung der Variablen, die all diese Hashes enthält, ist begrenzt. Es wird einfach nicht genug Platz vorhanden sein, um jedes Mal einen neuen Satz von Hashes hinzuzufügen, wenn festgestellt wird, dass GRUB (der Bootloader, der ursprünglich in einer Zeit geschrieben wurde, als kein Schutz beim Booten praktiziert wurde und mehrere separate Parser für img-Images sowie einen Schriftparser hat) einen weiteren Mechanismus hat, um den Angreifer dazu zu bringen, beliebigen Code auszuführen, weshalb eine andere Lösung erforderlich war.
Diese Lösung wurde SBAT genannt. Das Grundkonzept von SBAT ist ziemlich einfach. Jeder wichtige Bestandteil der Bootkette gibt eine Sicherheitsgeneration an, die in die signierte Binärdatei aufgenommen wird. Wenn eine Verwundbarkeit entdeckt und behoben wird, wird diese Generation erhöht. Danach kann ein Update veröffentlicht werden, das die minimale Generation definiert – die Bootkomponenten schauen sich das nächste Element in der Kette an, vergleichen dessen Namen und Generation mit den in der Firmware gespeicherten und entscheiden, ob es ausgeführt werden soll oder nicht. Anstatt eine Vielzahl einzelner Hashes zurückzurufen, kann ein einziges Update veröffentlicht werden, das einfach sagt: „Jede Version von GRUB mit einer Sicherheitsgeneration unter dieser Nummer wird als nicht vertrauenswürdig angesehen.“
Warum ist das plötzlich relevant geworden? SBAT wurde gemeinsam von der Linux-Community und Microsoft entwickelt, und Microsoft entschied sich, ein Update für Windows herauszugeben, das den Systemen sagte, dass sie Versionen von GRUB mit einer Sicherheitsgeneration unter einem bestimmten Niveau nicht vertrauen sollten. Dies geschah, weil diese GRUB-Versionen echte Sicherheitsanfälligkeiten aufwiesen, die es Angreifern ermöglichten, die Secure-Boot-Kette von Windows zu unterbrechen, und wir haben echte Beispiele für Malware gesehen, die dies wollte (Black Lotus nutzte eine Verwundbarkeit im Windows-Bootloader, aber die Verwundbarkeit in GRUB war ebenso effektiv). Wenn man das rein aus Sicherheitsgründen betrachtet, ist das ein durchaus legitimes Anliegen.
Was das Problem mit der Meldung „Es ist etwas völlig schiefgelaufen“ und der Unmöglichkeit der Installation aufgrund dieses Updates betrifft. Es stammt von Shim und nicht von irgendeinem Code von Microsoft. Shim berücksichtigt die SBAT-Updates, und um die Sicherheitsprinzipien, die von anderen Bootloadern im System übernommen wurden, nicht zu verletzen, und obwohl Microsoft ein SBAT-Update veröffentlicht hat, lehnt der Linux-Bootloader infolgedessen das Starten älterer GRUB-Versionen ab. Alles funktioniert so, wie es sollte.
Das Problem, mit dem Menschen konfrontiert waren, liegt darin, dass mehrere Linux-Distributionen keine GRUB-Versionen mit einem neueren Sicherheitsgeneration veröffentlicht haben, weshalb diese GRUB-Versionen als unsicher gelten (es ist erwähnenswert, dass GRUB von den Distributionen selbst und nicht von Microsoft signiert wird, sodass hier keine externe Verzögerung vorliegt). Im Sinne von Microsoft sollte das Windows-Update das SBAT-Update nur auf Systeme anwenden, die ausschließlich mit Windows arbeiten, während alle Dual-Boot-Installationen bis zur Aktualisierung von GRUB durch die installierte Distribution weiterhin anfällig für Angriffe bleiben. Leider, wie jetzt offensichtlich ist, hat dies nicht so funktioniert, wie es beabsichtigt war, und mindestens einige Dual-Boot-Systeme haben das Update angewendet, während Shim des betreffenden Distribution die GRUB-Version dieser Distribution nicht geladen hat.
Was ist das Fazit? Microsoft wollte aus verständlichen Gründen nicht, dass Windows durch eine verwundbare GRUB-Version angegriffen werden kann, die dazu verleitet werden könnte, beliebigen Code auszuführen, um dann einen Bootkit in den Windows-Kernel während des Startvorgangs einzufügen. Microsoft hat dies erreicht, indem es ein Windows-Update veröffentlicht hat, das die SBAT-Variable aktualisiert hat, und festlegte, dass verwundbare GRUB-Versionen auf diesen Systemen nicht geladen werden sollten. Der von der Distribution bereitgestellte Shim-Bootloader las diese Variable, las die SBAT-Partition der installierten GRUB-Kopie, erkannte den Konflikt und weigerte sich, grub mit der Meldung „Es ist etwas völlig schiefgelaufen“ zu laden. Dieses Update sollte nicht auf Dual-Boot-Systemen angewendet werden, wurde aber trotzdem angewendet.
Zusammenfassend:
1) Microsoft hat das Update auf Systeme angewendet, auf die es nicht hätte angewendet werden sollen.
2) Einige Linux-Distributionen haben den GRUB-Bootloader und die SBAT-Sicherheitsgeneration nicht aktualisiert, als in GRUB Schwachstellen entdeckt wurden.
Infolgedessen können einige Menschen ihre Systeme nicht starten. Ich denke, dass es hier viele Schuldige gibt. Microsoft sollte mehr Tests durchführen, um sicherzustellen, dass Dual-Boot-Installationen genau erkannt werden. Aber auch die Distributionen, die signierte Bootloader bereitstellen, müssen sicherstellen, dass sie diese aktualisieren und die Sicherheitsgeneration auf den aktuellen Stand bringen, denn ansonsten bieten sie einen Angriffsvektor, der zur Kompromittierung anderer Betriebssysteme genutzt werden kann, und das ist eine Art von Verletzung des sozialen Vertrags rund um das Ganze.
Leider sind hier hauptsächlich Endbenutzer betroffen, die plötzlich mit dem Problem konfrontiert sind, dass das System nicht die Betriebssystemversion lädt, die sie laden möchten. Das dürfte niemals passieren. Ich denke nicht, dass eine Umfrage unter Endbenutzern darüber, ob sie Updates für sichere Boot-Optionen wünschen, zu einem positiven Ergebnis führen wird, und obwohl ich vage geneigt bin zu glauben, dass sicheres Boot UEFI nichts ist, was den meisten Endbenutzern nützt, ist es auch etwas, das man nicht nach solchen Vorfällen entdecken möchte. Daher sympathisiere ich damit, dass es standardmäßig aktiviert ist, und unterstütze die Entscheidung von Microsoft, es als Standardaktivierung zu belassen, mit Ausnahme des gescheiterten Versuchs, Updates auf Systemen mit Dual Boot zu vermeiden.
Auf jeden Fall war ich 2012 stark in die Umsetzung dieses Mechanismus für Linux involviert und schrieb den ersten Prototyp von Shim (der jetzt ein deutlich besserer Bootloader ist, der von einer breiteren Nutzerbasis unterstützt wird und den ich seit mehreren Jahren nicht mehr angefasst habe). Wenn Sie also jemanden dafür verantwortlich machen möchten, fühlen Sie sich bitte nicht scheu, mich zu beschuldigen. Das hätte nicht passieren dürfen, und wenn Sie nicht Microsoft oder eine Linux-Distribution sind, ist es nicht Ihre Schuld. Ich entschuldige mich.
Quelle: opennet.ru
