Matthew Garrett, ein bekannter Linux-Kernel-Entwickler, der einst vom Open Source Fund für seinen Beitrag zur Entwicklung von Software ausgezeichnet wurde, erklärte die Funktionsweise des SBAT (Secure Boot Advanced Targeting), das geschaffen wurde, um Schwachstellen im Bootloader zu blockieren, ohne die digitale Signatur zurückzuziehen. Er sprach auch über dessen Rolle in dem kürzlichen Vorfall mit einem Update für Windows, das zum Ausfall des Starts einiger Linux-Distributionen führte, die parallel zu Windows auf Systemen mit aktiviertem UEFI Secure Boot installiert waren. Kurz gesagt, die Schuld trägt sowohl Microsoft, das das Update nicht vollständig getestet hat und es 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-Generationsnummer nicht aktualisiert haben, als Schwachstellen in GRUB entdeckt wurden.
Hier ist die Übersetzung von Garretts Notiz:
Als die Spezifikation für UEFI Secure Boot entwickelt wurde, waren alle Beteiligten, sagen wir mal, etwas naiv. Das Grundmodell der Sicherheitsarchitektur von Secure Boot besagt, dass sämtlicher Code, der in einer privilegierten Umgebung auf Kernelebene ausgeführt wird, vor seiner Ausführung überprüft werden muss – die Firmware überprüft den Bootloader, der Bootloader überprüft den Kernel, der Kernel überprüft jeden zusätzlich zur Laufzeit geladenen Code, und nun haben wir eine vertrauenswürdige Umgebung, um jede andere Sicherheitsrichtlinie durchzusetzen, die wir wünschen. Offensichtlich können Menschen Fehler machen, aber in der Spezifikation gab es einen Mechanismus zum Widerruf von signierten Komponenten, die als unsicher erachtet wurden: Fügen Sie einfach den Hash des nicht vertrauenswürdigen Codes in eine Variable ein und verweigern Sie das Laden von allem mit diesem Hash, selbst wenn es mit einem vertrauenswürdigen Schlüssel signiert ist.
Leider hat sich herausgestellt, dass das Problem von der Skalierung abhängt. Jede Linux-Distribution, die im Secure Boot-Ökosystem läuft, generiert ihre eigenen Bootloader-Binärdateien, und jede davon hat ihren eigenen Hash. Wenn im Quellcode eines solchen Bootloaders eine Schwachstelle entdeckt wird, müssen viele verschiedene Binärdateien zurückgezogen werden. Der Speicherplatz für die Variable, die all diese Hashes enthält, ist jedoch begrenzt. Es reicht einfach nicht aus, um jedes Mal ein neues Hash-Set hinzuzufügen, wenn festgestellt wird, dass GRUB (der Bootloader, der ursprünglich in einer Zeit geschrieben wurde, als Boot-Schutz nicht praktiziert wurde und der mehrere separate Parser für img-Images und auch einen Schriftarten-Parser hat) einen weiteren Mechanismus bietet, über den ein Angreifer ihn zwingen kann, beliebigen Code auszuführen. Daher war eine andere Lösung erforderlich.
Die Lösung dafür ist SBAT. Das Grundkonzept von SBAT ist recht einfach. Jede wichtige Komponente in der Bootkette gibt eine Sicherheitsgeneration an, die in die signierte Binärdatei integriert wird. Wenn eine Schwachstelle entdeckt und behoben wird, wird diese Generation erhöht. Dann kann ein Update veröffentlicht werden, das die minimale Generation definiert – die Bootkomponenten werden das nächste Element in der Kette betrachten, dessen Namen und Generationsnummer mit den in der Firmware-Variable gespeicherten vergleichen und entscheiden, ob sie es ausführen oder nicht. Anstatt eine große Anzahl individueller Hashes zurückzurufen, kann ein einfaches Update veröffentlicht werden, das lediglich besagt: „Jede GRUB-Version 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 hat ein Update für Windows veröffentlicht, das den Systemen sagte, dass sie GRUB-Versionen mit einer Sicherheitsgeneration unter einem bestimmten Niveau nicht vertrauen sollen. Dies wurde gemacht, weil diese GRUB-Versionen echte Sicherheitsanfälligkeiten hatten, die es Angreifern ermöglichten, die sichere Bootkette von Windows zu unterbrechen, und wir haben konkrete Beispiele für Malware gesehen, die dies anstreben wollte (Black Lotus nutzte eine Schwachstelle im Windows-Bootloader, aber die Schwachstelle in GRUB war ebenso effektiv). Aus einer rein sicherheitstechnischen Perspektive ist dieser Wunsch durchaus legitim.
Was die Nachricht "Etwas ist schief gelaufen" und das daraus resultierende Unvermögen, nach diesem Update zu booten, betrifft. Diese wird von shim ausgegeben, und nicht von irgendeinem Code von Microsoft. Shim berücksichtigt die SBAT-Updates, und um die Sicherheitsprinzipien, die von anderen Bootloadern im System akzeptiert wurden, nicht zu verletzen, lehnte der Linux-Bootloader im Ergebnis ab, alte GRUB-Versionen zu starten, auch wenn Microsoft das SBAT-Update veröffentlicht hat. Alles funktioniert so, wie es sollte.
Das Problem, mit dem die Menschen konfrontiert sind, besteht darin, dass mehrere Linux-Distributionen keine Versionen von GRUB mit einer neueren Sicherheitsgeneration herausgebracht haben, weshalb diese Versionen von GRUB als unsicher gelten (es sei darauf hingewiesen, dass GRUB von den Distributionen selbst signiert wird und nicht von Microsoft, sodass hier kein externes Nachlassen vorliegt). Laut Microsoft sollte das Windows Update das SBAT-Update nur auf Systemen anwenden, die ausschließlich mit Windows betrieben werden, während alle Dual-Boot-Installationen bis zur Aktualisierung von GRUB durch die installierte Distribution anfällig für Angriffe bleiben würden. Leider hat sich nun gezeigt, dass dies nicht wie geplant funktioniert hat und zumindest einige Dual-Boot-Systeme das Update angewendet haben, während Shim dieser Distribution sich weigerte, GRUB dieser Distribution zu laden.
Was ist das Ergebnis? Microsoft wollte aus verständlichen Gründen nicht, dass Windows durch eine verwundbare Version von GRUB angegriffen werden kann, die dazu gebracht wird, beliebigen Code auszuführen und dann einen Bootkit in den Windows-Kernel während des Startvorgangs einzufügen. Microsoft hat dies erreicht, indem es ein Windows-Update herausgegeben hat, das die SBAT-Variable aktualisierte und besagte, dass verwundbare GRUB-Versionen auf diesen Systemen nicht geladen werden dürfen. Der bereitgestellte Shim-Bootloader las diese Variable, las den SBAT-Abschnitt aus der installierten GRUB-Kopie, erkannte, dass sie in Konflikt standen, und weigerte sich, GRUB mit der Meldung „Etwas ist ganz schiefgelaufen“ zu laden. Dieses Update sollte nicht auf Dual-Boot-Systemen angewendet werden, wurde jedoch trotzdem angewendet.
Zusammenfassend:
1) Microsoft hat das Update auf Systeme angewendet, auf die es nicht angewendet werden sollte.
2) Einige Linux-Distributionen haben den GRUB-Bootloader und die Sicherheitsgeneration SBAT nicht aktualisiert, als Schwachstellen in GRUB entdeckt wurden.
Infolgedessen können einige Menschen ihre Systeme nicht laden. Ich denke, es gibt viele Verantwortliche dafür. Microsoft sollte umfangreichere Tests durchführen, um sicherzustellen, dass Dual-Boot-Installationen korrekt erkannt werden können. Aber auch die Distributionen, die signierte Bootloader bereitstellen, müssen sicherstellen, dass sie diese aktualisieren und die Sicherheitsgeneration entsprechend anpassen, denn andernfalls bieten sie einen Angriffsvektor, der zum Hacken anderer Betriebssysteme verwendet werden kann, und das stellt eine Art Verletzung des sozialen Vertrags rund um das Ganze dar.
Leider sind hier hauptsächlich Endbenutzer betroffen, die damit konfrontiert sind, dass das System plötzlich die gewünschte OS nicht mehr lädt. Das sollte niemals passieren. Ich glaube nicht, dass eine Umfrage unter Endbenutzern über ihr Interesse an Updates für die sichere Boot-Funktion zu einem positiven Ergebnis führen wird, und obwohl ich leicht der Meinung bin, dass sich die UEFI-Sicherheitsfunktion nicht als vorteilhaft für die meisten Endbenutzer erweist, ist es auch etwas, das man nicht nach solchen Vorfällen entdecken möchte. Deshalb verstehe ich, dass sie standardmäßig aktiviert ist, und ich unterstütze die Entscheidung, sie standardmäßig zu aktivieren. Ich teile die Entscheidung von Microsoft, abgesehen von dem misslungenen Versuch, das Update auf Dual-Boot-Systemen 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 Gruppe von Menschen unterstützt wird und den ich seit mehreren Jahren nicht mehr berührt habe). Falls Sie also jemandem die Schuld geben möchten, zögern Sie bitte nicht, mich dafür verantwortlich zu machen. Das hätte nicht passieren dürfen, und wenn Sie nicht Microsoft oder eine Linux-Distribution sind, ist das nicht Ihre Schuld. Entschuldigung.
Quelle: opennet.ru
