Matthew Garrett, ein bekannter Linux-Kernel-Entwickler, der einst vom SPI-Stiftung f\u00fcr seinen Beitrag zur Entwicklung von Open Source Software ausgezeichnet wurde, sprach \u00fcber die Funktionsweise des SBAT (Secure Boot Advanced Targeting) Mechanismus, der entwickelt wurde, um Schwachstellen im Bootloader ohne Widerruf von digitalen Signaturen zu blockieren, sowie \u00fcber seine Rolle in dem k\u00fcrzlichen Vorfall mit einem Windows-Update, das dazu f\u00fchrte, dass einige Linux-Distributionen, die parallel zu Windows auf Systemen mit aktiviertem UEFI Secure Boot installiert waren, nicht mehr booten konnten. Kurz gesagt, daf\u00fcr 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. <\/p>\n
Nachfolgend die \u00dcbersetzung der Notiz von Garrett: <\/p>\n
\nAls die Spezifikation f\u00fcr UEFI Secure Boot entwickelt wurde, waren alle Beteiligten sagen wir, etwas naiv. Das Hauptsicherheitsmodell von Secure Boot besteht darin, dass jeglicher Code, der in einer privilegierten Umgebung auf Kernel-Ebene ausgef\u00fchrt wird, vor der Ausf\u00fchrung \u00fcberpr\u00fcft werden muss \u2014 die Firmware \u00fcberpr\u00fcft den Bootloader, der Bootloader \u00fcberpr\u00fcft den Kernel, der Kernel \u00fcberpr\u00fcft jeden zus\u00e4tzlich w\u00e4hrend der Laufzeit geladenen Kernel-Code, und jetzt haben wir eine vertrauensw\u00fcrdige Umgebung, um jede andere Sicherheitsrichtlinie durchzusetzen, die wir m\u00f6chten. Offenbar k\u00f6nnen Menschen Fehler machen, aber in der Spezifikation wurde ein Weg vorgesehen, um signierte Komponenten, die als unsicher erachtet werden, zur\u00fcckzuziehen: Man f\u00fcgt einfach den Hash des unsicheren Codes in eine Variable ein und weigert sich dann, irgendetwas mit diesem Hash zu laden, selbst wenn es mit einem vertrauensw\u00fcrdigen Schl\u00fcssel signiert ist. <\/p>\n
Leider hat sich herausgestellt, dass das Problem im Ma\u00dfstab liegt. Jede Linux-Distribution, die im Secure-Boot-\u00d6kosystem arbeitet, erzeugt ihre eigenen Bin\u00e4rdateien des Bootloaders, und jede von ihnen hat ihren eigenen Hash. Wenn im Quellcode eines solchen Bootloaders eine Verwundbarkeit entdeckt wird, m\u00fcssen eine Vielzahl unterschiedlicher Bin\u00e4rdateien zur\u00fcckgerufen werden. Der Speicherplatz f\u00fcr die Speicherung der Variablen, die all diese Hashes enth\u00e4lt, ist begrenzt. Es wird einfach nicht genug Platz vorhanden sein, um jedes Mal einen neuen Satz von Hashes hinzuzuf\u00fcgen, wenn festgestellt wird, dass GRUB (der Bootloader, der urspr\u00fcnglich in einer Zeit geschrieben wurde, als kein Schutz beim Booten praktiziert wurde und mehrere separate Parser f\u00fcr img-Images sowie einen Schriftparser hat) einen weiteren Mechanismus hat, um den Angreifer dazu zu bringen, beliebigen Code auszuf\u00fchren, weshalb eine andere L\u00f6sung erforderlich war. <\/p>\n
Diese L\u00f6sung wird als SBAT bezeichnet. Das allgemeine Konzept von SBAT ist ziemlich einfach. Jeder wichtige Bestandteil in der Bootkette erkl\u00e4rt die Sicherheitsgeneration, die in die signierte Bin\u00e4rdatei aufgenommen wird. Wenn eine Schwachstelle entdeckt und behoben wird, wird diese Generation erh\u00f6ht. Dann kann ein Update ver\u00f6ffentlicht werden, das die minimale Generation definiert \u2014 die Bootkomponenten werden das n\u00e4chste Element in der Kette betrachten, seinen Namen und die Generationsnummer mit denen vergleichen, die in der Firmware-Variablen gespeichert sind, und entscheiden, ob sie es ausf\u00fchren oder nicht. Anstatt eine gro\u00dfe Anzahl einzelner Hashes zur\u00fcckzurufen, kann ein einfaches Update herausgegeben werden, das besagt: \u201eJede Version von GRUB mit einer Sicherheitsgeneration unter dieser Nummer wird als nicht vertrauensw\u00fcrdig angesehen\u201c. <\/p>\n
Warum ist das pl\u00f6tzlich relevant geworden? SBAT wurde gemeinsam von der Linux-Community und Microsoft entwickelt, und Microsoft entschied sich, ein Update f\u00fcr 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\u00e4lligkeiten aufwiesen, die es Angreifern erm\u00f6glichten, die Secure-Boot-Kette von Windows zu unterbrechen, und wir haben echte Beispiele f\u00fcr 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\u00fcnden betrachtet, ist das ein durchaus legitimes Anliegen. <\/p>\n
Was die Meldung \u201eEtwas ist ganz schiefgelaufen\u201c und die Unm\u00f6glichkeit des Bootens nach diesem Update betrifft. Diese Meldung stammt von shim, und nicht von einem Code von Microsoft. Shim ber\u00fccksichtigt die SBAT-Updates, und um die Sicherheitsprinzipien, die von anderen Bootloadern im System angenommen wurden, nicht zu verletzen, und obwohl auch Microsoft ein SBAT-Update herausgegeben hat, lehnt der Linux-Bootloader letztendlich ab, alte Versionen von GRUB zu starten. Alles funktioniert so, wie es sollte. <\/p>\n
Das Problem, mit dem Menschen konfrontiert waren, liegt darin, dass mehrere Linux-Distributionen keine GRUB-Versionen mit einem neueren Sicherheitsgeneration ver\u00f6ffentlicht haben, weshalb diese GRUB-Versionen als unsicher gelten (es ist erw\u00e4hnenswert, dass GRUB von den Distributionen selbst und nicht von Microsoft signiert wird, sodass hier keine externe Verz\u00f6gerung vorliegt). Im Sinne von Microsoft sollte das Windows-Update das SBAT-Update nur auf Systeme anwenden, die ausschlie\u00dflich mit Windows arbeiten, w\u00e4hrend alle Dual-Boot-Installationen bis zur Aktualisierung von GRUB durch die installierte Distribution weiterhin anf\u00e4llig f\u00fcr 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\u00e4hrend Shim des betreffenden Distribution die GRUB-Version dieser Distribution nicht geladen hat. <\/p>\n
Was ist das Fazit? Microsoft wollte aus verst\u00e4ndlichen Gr\u00fcnden nicht, dass Windows durch eine verwundbare Version von GRUB angegriffen werden kann, die dazu gebracht werden k\u00f6nnte, beliebigen Code auszuf\u00fchren und dann einen Bootkit in den Windows-Kernel w\u00e4hrend des Bootvorgangs einzuf\u00fcgen. Microsoft hat dies erreicht, indem es ein Windows-Update ver\u00f6ffentlicht hat, das die SBAT-Variable aktualisierte und angab, dass verwundbare Versionen von GRUB auf diesen Systemen nicht geladen werden d\u00fcrfen. Der von der Distribution bereitgestellte Shim-Bootloader f\u00fcr die erste Phase las diese Variable, las den SBAT-Abschnitt von der installierten GRUB-Kopie, erkannte, dass es Konflikte gab, und verweigerte das Laden von grub mit der Meldung \u201eIrgendwas ist ganz schiefgelaufen\u201c. Dieses Update sollte nicht auf Dual-Boot-Systemen angewendet werden, wurde jedoch trotzdem angewendet. <\/p>\n
Zusammenfassend: <\/p>\n
1) Microsoft hat das Update auf Systeme angewendet, auf die es nicht h\u00e4tte angewendet werden sollen. <\/p>\n
2) Einige Linux-Distributionen haben den GRUB-Bootloader und die SBAT-Sicherheitsgeneration nicht aktualisiert, als in GRUB Schwachstellen entdeckt wurden. <\/p>\n
Infolgedessen k\u00f6nnen einige Menschen ihre Systeme nicht starten. Ich denke, dass es hier viele Schuldige gibt. Microsoft sollte mehr Tests durchf\u00fchren, um sicherzustellen, dass Dual-Boot-Installationen genau erkannt werden. Aber auch die Distributionen, die signierte Bootloader bereitstellen, m\u00fcssen 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. <\/p>\n
Leider sind hier haupts\u00e4chlich Endbenutzer betroffen, die pl\u00f6tzlich mit dem Problem konfrontiert sind, dass das System nicht die Betriebssystemversion l\u00e4dt, die sie laden m\u00f6chten. Das d\u00fcrfte niemals passieren. Ich denke nicht, dass eine Umfrage unter Endbenutzern dar\u00fcber, ob sie Updates f\u00fcr sichere Boot-Optionen w\u00fcnschen, zu einem positiven Ergebnis f\u00fchren wird, und obwohl ich vage geneigt bin zu glauben, dass sicheres Boot UEFI nichts ist, was den meisten Endbenutzern n\u00fctzt, ist es auch etwas, das man nicht nach solchen Vorf\u00e4llen entdecken m\u00f6chte. Daher sympathisiere ich damit, dass es standardm\u00e4\u00dfig aktiviert ist, und unterst\u00fctze die Entscheidung von Microsoft, es als Standardaktivierung zu belassen, mit Ausnahme des gescheiterten Versuchs, Updates auf Systemen mit Dual Boot zu vermeiden. <\/p>\n
Auf jeden Fall war ich 2012 stark in die Umsetzung dieses Mechanismus f\u00fcr Linux involviert und schrieb den ersten Prototyp von Shim (der jetzt ein deutlich besserer Bootloader ist, der von einer breiteren Nutzerbasis unterst\u00fctzt wird und den ich seit mehreren Jahren nicht mehr angefasst habe). Wenn Sie also jemanden daf\u00fcr verantwortlich machen m\u00f6chten, f\u00fchlen Sie sich bitte nicht scheu, mich zu beschuldigen. Das h\u00e4tte nicht passieren d\u00fcrfen, und wenn Sie nicht Microsoft oder eine Linux-Distribution sind, ist es nicht Ihre Schuld. Ich entschuldige mich. <\/p><\/blockquote>\n