Matthew Garrett, ein bekannter Linux-Kernel-Entwickler, der einst vom Open Source Fund f\u00fcr seinen Beitrag zur Entwicklung von Software ausgezeichnet wurde, erkl\u00e4rte die Funktionsweise des SBAT (Secure Boot Advanced Targeting), das geschaffen wurde, um Schwachstellen im Bootloader zu blockieren, ohne die digitale Signatur zur\u00fcckzuziehen. Er sprach auch \u00fcber dessen Rolle in dem k\u00fcrzlichen Vorfall mit einem Update f\u00fcr Windows, das zum Ausfall des Starts einiger Linux-Distributionen f\u00fchrte, die parallel zu Windows auf Systemen mit aktiviertem UEFI Secure Boot installiert waren. Kurz gesagt, die Schuld tr\u00e4gt sowohl Microsoft, das das Update nicht vollst\u00e4ndig 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. <\/p>\n
Hier ist die \u00dcbersetzung von Garretts Notiz: <\/p>\n
\nAls die Spezifikation f\u00fcr UEFI Secure Boot erstellt wurde, waren alle Beteiligten, sagen wir mal, ein wenig naiv. Das Hauptsicherheitsmodell von Secure Boot besagt, dass jeder Code, der in einer privilegierten Umgebung auf Kernel-Ebene ausgef\u00fchrt wird, vor der Ausf\u00fchrung \u00fcberpr\u00fcft werden muss \u2013 die Firmware \u00fcberpr\u00fcft den Bootloader, der Bootloader \u00fcberpr\u00fcft den Kernel, der Kernel \u00fcberpr\u00fcft jeden zus\u00e4tzlich w\u00e4hrend der Laufzeit geladenen Kerncode, und nun haben wir eine vertrauensw\u00fcrdige Umgebung, um jede andere Sicherheitsrichtlinie durchzusetzen, die wir wollen. Offensichtlich k\u00f6nnen Menschen Fehler machen, aber in der Spezifikation gab es einen Mechanismus zur Widerrufung von signierten Komponenten, die als unsicher erwiesen wurden: F\u00fcgen Sie einfach den Hash von nicht vertrauensw\u00fcrdigem Code in eine Variable ein und weigern Sie sich, alles 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 von der Skalierung abh\u00e4ngt. Jede Linux-Distribution, die im Secure Boot-\u00d6kosystem l\u00e4uft, generiert ihre eigenen Bootloader-Bin\u00e4rdateien, und jede davon hat ihren eigenen Hash. Wenn im Quellcode eines solchen Bootloaders eine Schwachstelle entdeckt wird, m\u00fcssen viele verschiedene Bin\u00e4rdateien zur\u00fcckgezogen werden. Der Speicherplatz f\u00fcr die Variable, die all diese Hashes enth\u00e4lt, ist jedoch begrenzt. Es reicht einfach nicht aus, um jedes Mal ein neues Hash-Set hinzuzuf\u00fcgen, wenn festgestellt wird, dass GRUB (der Bootloader, der urspr\u00fcnglich in einer Zeit geschrieben wurde, als Boot-Schutz nicht praktiziert wurde und der mehrere separate Parser f\u00fcr img-Images und auch einen Schriftarten-Parser hat) einen weiteren Mechanismus bietet, \u00fcber den ein Angreifer ihn zwingen kann, beliebigen Code auszuf\u00fchren. Daher war eine andere L\u00f6sung erforderlich. <\/p>\n
Diese L\u00f6sung nennt sich SBAT. Das grundlegende Konzept von SBAT ist ziemlich einfach. Jede wichtige Komponente in der Bootkette erkl\u00e4rt eine Sicherheitsgeneration, die in die signierte Bin\u00e4rdatei aufgenommen wird. Sobald eine Schwachstelle entdeckt und behoben wurde, wird diese Generation erh\u00f6ht. Anschlie\u00dfend kann ein Update bereitgestellt werden, das die minimale Generation definiert \u2013 die Bootkomponenten \u00fcberpr\u00fcfen das n\u00e4chste Element in der Kette, vergleichen dessen Namen und Generation mit den in der Firmware gespeicherten und entscheiden, ob sie es ausf\u00fchren oder nicht. Anstatt eine gro\u00dfe Anzahl einzelner Hashes zu widerrufen, kann ein einziges Update bereitgestellt werden, das einfach sagt: \u201eJede Version von GRUB mit einer Sicherheitsgeneration unter dieser Nummer gilt als nicht vertrauensw\u00fcrdig.\u201c <\/p>\n
Warum ist das pl\u00f6tzlich relevant geworden? SBAT wurde gemeinsam von der Linux-Community und Microsoft entwickelt, und Microsoft hat ein Update f\u00fcr Windows ver\u00f6ffentlicht, 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\u00e4lligkeiten hatten, die es Angreifern erm\u00f6glichten, die sichere Bootkette von Windows zu unterbrechen, und wir haben konkrete Beispiele f\u00fcr 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. <\/p>\n
Nun zum Problem \u201eIrgendwas ist schief gelaufen\u201c und der Unf\u00e4higkeit, aufgrund dieses Updates zu booten. Dies wird von Shim ausgegeben, nicht von irgendeinem Code von Microsoft. Shim ber\u00fccksichtigt die SBAT-Updates und um die Sicherheitsprinzipien, die von anderen Bootloadern im System \u00fcbernommen wurden, nicht zu verletzen. Obwohl Microsoft ein SBAT-Update ver\u00f6ffentlicht hat, weigert sich der Linux-Bootloader, die alten Versionen von GRUB zu starten. Alles funktioniert also wie es sollte. <\/p>\n
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\u00dflich mit Windows betrieben werden, w\u00e4hrend alle Dual-Boot-Installationen bis zur Aktualisierung von GRUB durch die installierte Distribution anf\u00e4llig f\u00fcr Angriffe bleiben w\u00fcrden. Leider hat sich nun gezeigt, dass dies nicht wie geplant funktioniert hat und zumindest einige Dual-Boot-Systeme das Update angewendet haben, w\u00e4hrend Shim dieser Distribution sich weigerte, GRUB dieser Distribution zu laden. <\/p>\n
Was ist das Fazit? Microsoft wollte (aus verst\u00e4ndlichen Gr\u00fcnden) nicht, dass Windows durch eine verwundbare Version von GRUB angegriffen wird, die dazu gebracht werden k\u00f6nnte, beliebigen Code auszuf\u00fchren und dann einen Bootkit in den Windows-Kernel w\u00e4hrend des Bootvorgangs einzuf\u00fchren. Microsoft hat dies durch die Ver\u00f6ffentlichung eines Windows-Updates erreicht, das die SBAT-Variable aktualisierte, um anzugeben, dass verwundbare GRUB-Versionen auf diesen Systemen nicht geladen werden sollten. Der von der Distribution bereitgestellte Shim-Bootloader las diese Variable, las den SBAT-Bereich aus der installierten GRUB-Kopie, erkannte den Konflikt und weigerte sich, grub mit der Meldung \u201eIrgendwas ist schief gelaufen\u201c zu laden. Dieses Update sollte nicht auf Dual-Boot-Systemen angewendet werden, wurde jedoch dennoch angewendet. <\/p>\n
Zusammenfassend: <\/p>\n
1) Microsoft hat das Update auf Systeme angewendet, auf die es nicht angewendet werden sollte. <\/p>\n
2) Einige Linux-Distributionen haben den GRUB-Bootloader und die Sicherheitsgeneration SBAT nicht aktualisiert, als Schwachstellen in GRUB entdeckt wurden. <\/p>\n
Infolgedessen k\u00f6nnen einige Menschen ihre Systeme nicht laden. Ich denke, es gibt viele Verantwortliche daf\u00fcr. Microsoft sollte umfangreichere Tests durchf\u00fchren, um sicherzustellen, dass Dual-Boot-Installationen korrekt erkannt werden k\u00f6nnen. Aber auch die Distributionen, die signierte Bootloader bereitstellen, m\u00fcssen 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. <\/p>\n
Leider sind hier haupts\u00e4chlich Endbenutzer betroffen, die damit konfrontiert sind, dass das System pl\u00f6tzlich die gew\u00fcnschte OS nicht mehr l\u00e4dt. Das sollte niemals passieren. Ich glaube nicht, dass eine Umfrage unter Endbenutzern \u00fcber ihr Interesse an Updates f\u00fcr die sichere Boot-Funktion zu einem positiven Ergebnis f\u00fchren wird, und obwohl ich leicht der Meinung bin, dass sich die UEFI-Sicherheitsfunktion nicht als vorteilhaft f\u00fcr die meisten Endbenutzer erweist, ist es auch etwas, das man nicht nach solchen Vorf\u00e4llen entdecken m\u00f6chte. Deshalb verstehe ich, dass sie standardm\u00e4\u00dfig aktiviert ist, und ich unterst\u00fctze die Entscheidung, sie standardm\u00e4\u00dfig zu aktivieren. Ich teile die Entscheidung von Microsoft, abgesehen von dem misslungenen Versuch, das Update auf Dual-Boot-Systemen 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 Gruppe von Menschen unterst\u00fctzt wird und den ich seit mehreren Jahren nicht mehr ber\u00fchrt habe). Falls Sie also jemandem die Schuld geben m\u00f6chten, z\u00f6gern Sie bitte nicht, mich daf\u00fcr verantwortlich zu machen. Das h\u00e4tte nicht passieren d\u00fcrfen, und wenn Sie nicht Microsoft oder eine Linux-Distribution sind, ist das nicht Ihre Schuld. Entschuldigung. <\/p><\/blockquote>\n