[foobar]

Moin!

Zur Sicherheit der Hinweis, dass potentielle Startprobleme auf Windows-Nutzer zukommen, die UEFI Secure Boot verwenden. Solche Probleme sind insgesamt wohl eher unwahrscheinlich, aber möglich. Und wenn es passiert, sind sie mitunter schwer zu beheben. Ein TLDR findet sich am Ende dieses Posts.

Dass die UEFI-Spezifikation im Allgemeinen und Secure Boot im Speziellen fundamentale Designfehler enthalten, ist schon lange kein Geheimnis mehr. Eines der Probleme ist, dass man auf Teufel komm raus möglichst viel Kram im Firmware-Speicher des Mainboards hinterlegen wollte. Dieser Dummfug, zusammen mit weiteren Lücken in der Spezifikation, rächt sich nun.

Was ist das Problem? Hier der Schnelldurchlauf: Secure Boot soll dafür sorgen, dass nur „vertrauenswürdige” Bootloader gestartet werden. Die laden ihrerseits nur vertrauenswürdige Betriebssysteme, die nur vertrauenswürdige Treiber laden und so weiter. Und am Ende ist man sicher von Bootsektorviren und Rootkits und dergleichen. So jedenfalls die Versprechen der Industrie und die würden uns natürlich niemals anlügen. Und am besten stellt man keine lästigen Nachfragen wie: „Vertrauenswürdig – für wen?” oder „Wer entscheidet das?” Damit befassen wir uns hier auch nicht, der Post ist auch so schon lang genug.

Vereinfacht gesagt ist die Idee hinter Secure Boot, dass in der Mainboard-Firmware ein Zertifikat hinterlegt ist. Der Bootloader muss gegen dieses Zertifikat signiert sein, sonst führt ihn die Firmware des Boards nicht aus. Aber was ist, wenn sich im Nachgang, also nachdem der Bootloader seinen Prüfstempel erhalten hat, heraus stellt, dass er doch Sicherheitslücken oder andere Probleme hatte, die ihn nicht mehr vertrauenswürdig machen? Würde man das Zertifikat für sich ungültig machen, wären mit einem Schlag alle Bootloader tot. Statt dessen gibt es eine separate Sperrliste (im UEFI-Jargon DBX genannt). In der stehen die Prüfsummen von allen nachträglich gesperrten Bootloadern. Die werden auch dann nicht gestartet, wenn sie eine gültige Signatur aufweisen können. Damit man sich nicht nur auf die BIOS-Updates des Mainboard-Herstellers verlassen muss, kann auch das Betriebssystem die DBX aktualisieren – wovon Windows regelmäßig Gebrauch macht.

Nun war es natürlich für das UEFI-Forum absolut unvorhersehbar, dass diese Liste im Laufe der Zeit immer weiter anwachsen würde. Denn unsichere, alte Bootloader bleiben logischerweise unsicher, also wird nie ein Eintrag gelöscht. Aber es kommen ständig neue hinzu. Und manche Lücken betreffen aufgrund einer gemeinsamen Codebasis mehrere Bootloader zusammen, die dann alle einzeln in die Liste müssen. So kann eine einzige neue Lücke zu Dutzenden von Einträgen führen. Aber da konnte ja niemand mit rechnen. Also schreibt die UEFI-Spezifikation auch nicht vor, wie viel Platz genau nun für die DBX im Firmware-Speicher des Mainboards vorgehalten werden soll.

Auf vielen Boards sind es nur 32KB und das ist eine Grenze, der wir uns nun, nach einigen Jahren in der schönen neuen UEFI-Welt, langsam annähern. Das Konzept droht also an sich selbst zu scheitern. Damit das nicht passiert, müssen jetzt die Betriebssystemhersteller versuchen, um das Problem herum zu arbeiten.

Microsofts Lösung mit dem klingenden Namen „Code Integrity Boot Policy” sieht so aus, dass der Windows-Bootloader seine eigene Sperrliste in der verstecken EFI-Partition vorhält (in der mehr Platz ist als im Speicher des Mainboards). Der Bootloader startet also erst einmal, wirft das Windows an und selbiges prüft, ob es überhaupt hätte gebootet werden sollen und steigt ggf. mit einem BSOD wieder aus. Wem sich an dieser Stelle die Fußnägel aufrollen, hat’s verstanden. Welche Bootloader genau Microsoft nun in diese Sperrliste packt, verraten sie natürlich nicht. Alle öffentlich verfügbaren Listen (bspw. die des UEFI-Forums) sind unvollständig. Wann das entsprechende Update scharf geschaltet wird (die Funktionalität an sich ist offenbar bereits vorhanden), weiß man aktuell auch nicht genau. Vielleicht noch im Mai, vielleicht im Oktober, vielleicht nächstes Jahr. Windows-User sein bleibt also spannend.

Es ist ferner ein DoS-Angriff per USB-Stick auf den Rechner möglich, sofern das betreffende Update von MS noch nicht aktiviert wurde. Das geht so: Zusammen mit der Sperrliste werden zwei Variablen in der UEFI-Firmware gesetzt. Die Firmware ignoriert die, nur der Bootloader interessiert sich für sie. Fehlen sowohl die Sperrlistendatei als auch die Variablen, startet Windows einfach so. Ist beides vorhanden, erfolgt die o.g. Prüfung. Fehlen die Variablen, aber die Sperrliste ist da, setzt Windows die Variablen. Und sind Variablen gesetzt, aber die Sperrliste fehlt, dann stellt sich der Bootloader einfach tot. Soll wohl verhindern, dass ein Angreifer die Liste einfach löscht. Ich muss also auf einem Rechner nur einen USB-Stick mit bootfähigem Windows und Sperrliste einstecken und einmal davon starten. Dann wird der Loader auf dem Stick die Variablen setzen. Beim nächsten Start des installierten Windows stellt dessen Bootloader dann fest, dass es keine Sperrliste gibt (das Update fehlt ja noch). Also stellt er sich tot und der Rechner startet nicht mehr. Da hilft auch keine Neuinstallation, weil die UEFI-Variablen dabei nicht gelöscht werden. So kann man sich auch selbst ins Knie schießen, wenn man bspw. mit einem neu erstellten Windows-Rettungsmedium an einen isoliert stehenden PC geht, der bewusst nicht auf dem neuesten Stand gehalten wurde.

TLDR: UEFI und speziell Secure Boot sind kaputt ab Werk und in Zukunft wird das System noch mal eine ganze Stufe komplexer und damit fehleranfälliger. Die einfachste Lösung dürfte sein, zumindest Secure Boot einfach abzuschalten. Nutzer von Bitlocker sollten aber vorher auf jeden Fall den Wiederherstellungsschlüssel sichern, falls noch nicht geschehen. Denn Bitlocker reagiert allergisch auf Änderungen der UEFI-Einstellungen. Es kann sein, dass es einen Angriff vermutet, wenn Secure Boot plötzlich weg ist und nach dem Schlüssel fragt.

Panik ist nicht notwendig, aber eventuell möchte der eine andere seine Backup-Strategie überdenken und mal gucken, ob Secure Boot wirklich nötig ist. Noch ist Zeit, daher dieser Hinweis.

[Homerclon]

Jaja, überall wo "Secure" oder "Trusted" drauf steht, sollte man mit Skepsis begegnen.

[foobar]

Insbesondere, wenn ausgerechnet Microsoft sich zum Hüter über die Sicherheit aufschwingt. Sie haben gerade erst wieder vom CSRB (quasi dem amerikanischen Äquivalent zum deutschen BSI) einen abgewatscht bekommen. Das Board hatte sich den Fall aus dem letzten Jahr angesehen, als Microsoft sich einen Key Signing Schlüssel (der an der Wurzel der Vertrauenskette steht, sozusagen die sicherheitstechnischen Kronjuwelen) hatte klauen lassen. Dabei kam es unter anderem zu dem Ergebnis, dass MS nicht die Sicherheitsstandards anderer Cloudprovider wie Amazon oder Google einhält (und IMHO kann man da auch fragen, wie hoch selbige die Latte überhaupt legen), dass eine Reihe dummer und vermeidbarer Fehler zusammen kann und dass sie ihre Kunden belogen haben. Beispielsweise haben sie behauptet, sie wüssten, wie es zu dem Vorfall kommen konnte: Der Key wäre auf einem Entwicklungsrechner durch einen Crashdump in einem ungesicherten Speicherbereich gelandet. Im Nachgang stellte sich dann heraus, dass sie keinerlei Belege für diese These hatten. Die Erklärung ist also genauso gut wie zwei Dutzend andere. Sie haben sich einfach irgendwas aus den Fingern gesaugt, das nachvollziehbar klingt und wo die Kunden sagen: „Ok, das hätte mir auch passieren können. Da will ich mal nicht so pingelig sein.” Tatsächlich weiß MS bis heute nicht, wie genau ihnen der Key jetzt abhanden gekommen ist.

Davor gab es den Fall, dass ein anderer Key, der eigentlich schon in 2016 abgelaufen war, weiterhin gültige Token ausstellen konnte. Ursache? MS trennt in seiner Cloud zwischen Geschäftskunden und Endverbrauchern. Während bei ersteren die Schlüssel regelmäßig und automatisch ausgewechselt werden, um die Konsequenzen einer eventuellen Kompromittierung zu begrenzen, war die Herangehensweise für die normalen Verbraucher: Ach, das setzen wir da irgendwann bei Gelegenheit auch noch mal um. Was aber nie geschah und so haben sie die Schlüssel nur unregelmäßig und von Hand getauscht. Bei einem solchen manuellen Wechsel kam es dann zu einem Ausfall der Cloud und danach hat man den Schlüsselwechsel dann ganz unterlassen, damit die Cloud auch immer schön weiter läuft.

Das CSRB summiert seinen Bericht wie folgt:

The Board finds that this intrusion was preventable and should never have occurred. The Board also concludes that Microsoft’s security culture was inadequate and requires an overhaul

[...]

The Board reaches this conclusion based on:
1. the cascade of Microsoft’s avoidable errors that allowed this intrusion to succeed;
2. Microsoft’s failure to detect the compromise of its cryptographic crown jewels on its own, relying instead on a customer to reach out to identify anomalies the customer had observed;
3. the Board’s assessment of security practices at other cloud service providers, which maintained security controls that Microsoft did not;
4. Microsoft’s failure to detect a compromise of an employee's laptop from a recently acquired company prior to allowing it to connect to Microsoft’s corporate network in 2021;
5. Microsoft’s decision not to correct, in a timely manner, its inaccurate public statements about this incident, including a corporate statement that Microsoft believed it had determined the likely root cause of the intrusion when in fact, it still has not; even though Microsoft acknowledged to the Board in November 2023 that its September 6, 2023 blog post about the root cause was inaccurate, it did not update that post until March 12, 2024, as the Board was concluding its review and only after the Board’s repeated questioning about Microsoft’s plans to issue a correction;
6. the Board's observation of a separate incident, disclosed by Microsoft in January 2024, the investigation of which was not in the purview of the Board’s review, which revealed a compromise that allowed a different nation-state actor to access highly-sensitive Microsoft corporate email accounts, source code repositories, and internal systems; and
7. how Microsoft’s ubiquitous and critical products, which underpin essential services that support national security, the foundations of our economy, and public health and safety, require the company to demonstrate the highest standards of security, accountability, and transparency.

Kann MS natürlich letztlich egal sein, was das CSRB oder auch das BSI von ihnen hält. Was wollen die ganzen Regierungsbehörden in Deutschland oder den USA, deren vertraulichen Daten jetzt in den Händen der Chinesen und Russen sind, denn machen? Zu Linux wechseln? Machen wir uns mal nicht lächerlich!

[jabu]

Vielen Dank für die Warnung und die präzise und informative Darstellung des Problems.

Brutal verkürzt:
Der komplexe Abhängigkeitenzoo bei UEFI Secure Boot wird sich also rächen, und zwar voraussichtlich schon bald bei einigen Windows-Nutzern, woran Microsoft mitverursachend sein wird, da Microsoft nicht vorhat, einem die Entscheidung darüber zu lassen, einfach den problematischen Workaround und die Prüfsummen der am wenigsten realistischen Gefahren (von denen einige sogar unrealistisch sein könnten) ebenfalls wegzulassen.

Na, das klingt doch wieder superschlau, ungefähr wie neulich, als Microsoft bei einer Beta zu Windows 11 die Schaltfläche zum Anzeigen des Desktops aus der Taskleiste entfernt haben soll, worauf es natürlich einen Ansturm an Beschwerden gegeben haben soll, als ob bei solchen Ergonomiezerstörungen etwas anderes zu erwarten gewesen wäre. Ich könnte mir auch die Sitzfläche vom Stuhl abschrauben. Warum ist mir diese überaus intellente Idee bisher nicht in den Sinn gekommen?

[foobar]

da Microsoft nicht vorhat, einem die Entscheidung darüber zu lassen, einfach den problematischen Workaround und die Prüfsummen der am wenigsten realistischen Gefahren (von denen einige sogar unrealistisch sein könnten) ebenfalls wegzulassen.

Das ist AFAIK auch bei der DBX nicht vorgesehen. Offiziell, um zu verhindern, dass ein Angreifer eine veraltete DBX einspielt. Daher sind nur Ergänzungen möglich. Natürlich könnte der Angreifer dann auch eben die DBX mit Müll vollmachen und weitere Ergänzungen verhindern, aber wenigstens hat man ein bisschen mitgedacht. Nicht zu Ende, aber ein bisschen.

Die Open Source Gemeinde hat übrigens eine gänzlich andere Lösung entwickelt, die von Anfang an darauf ausgelegt wurde, nicht ständig ins Grenzenlose zu wachsen: SBAT (Secure Boot Advanced Targeting). Die Idee ist ebenso genial wie simpel: Alle am Startvorgang beteiligten Komponenten (Shim als Stage 1 Bootloader, GRUB als Stage 2 Loader, Kernel, Hypervisoren, etc.) kriegen eine Generationsnummer verpasst. Im Prinzip wie eine zweite Versionsnummer, die aber immer ganzzahlig ist (kein komplizierter Kram wie 42.0.8.15alpha1 oder so) und die nur hochgezählt wird, wenn eine sicherheitsrelevante Änderung statt gefunden hat.

Und dann muss man in der SBAT-Liste nur noch die letzte gesperrte (bzw. erste noch freigegebene) Generation des jeweiligen Produkts hinterlegen. Wenn GRUB z.B. mit Generation 3 in der Liste steht, dann ist implizit klar, dass alle Versionen der Generationen 1 und 2 nicht mehr sicher sind. Die müssen also nicht mehr alle einzeln mit insgesamt Hunderten von Einträgen gesperrt werden. Eine Zeile erschlägt i.d.R. die ganze Komponente.

Dann muss man nur noch verhindern, dass veraltete SBAT-Listen installiert werden (was über signierte Zeitstempel passiert) und... Bob’s your uncle.

Natürlich löst das nicht das grundsätzliche Problem, dass nun Betriebssysteme sich selbst nachträglich prüfen müssen (also quasi erst mal das Badewasser ausschütten und dann hinterher gucken, ob da noch ein Kind mit dabei war). Und es löst auch nicht die Abhängigkeit von Microsoft, da i.d.R. nur deren Zertifikat im Mainboard vorinstalliert ist (was ja zur Entwicklung von Shim führte, damit man nicht jede Version von GRUB absegnen lassen muss). Aber es ist zumindest eine clevere, zukunftssichere Lösung im Rahmen dessen, was die Community halt beeinflussen kann. Und die obendrein transparent ist: Die SBAT ist eine stinknormale CSV-Datei, in die jeder reingucken kann, der will.