Vorsicht vor UEFI Secure Boot: Mögliche Startprobleme in den kommenden Monaten

[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? :p

[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.

[foobar]

Es gibt übrigens Neuigkeiten: Microsoft hat es sich anders überlegt.

Man hat in Redmond den alten, hirnrissigen Plan verworfen und sich statt dessen einen neuen, hirnrissigen Plan ausgedacht. Es ist nämlich jemandem aufgefallen, dass die aktuellen Zertifikate, gegen die alle Bootloader signiert sind, sowieso in 2026 auslaufen. Und dann sind keine neuen Signaturen mehr möglich.

Da dachte man sich dann: Wenn wir die Zertifikate eh austauschen müssen, können wir das auch vorziehen und dann einfach das alte Zertifikat widerrufen (also in der DBX-Sperrliste eintragen). Dann werden mit einem Schlag alle alten Bootloader geblockt, ob sie nun wirklich unsicher sind oder nicht.

Und das wird nun – sofern sich bis dahin nicht wieder was ändert – in den kommenden Monaten erfolgen. Dazu wird also zuerst durch Windows Update ein neues Zertifikat eingespielt, dann ein neuer Bootloader und dann das alte Zertifikat gesperrt. Das muss genau in dieser Reihenfolge passieren und es darf nichts schief gehen, sonst startet der Rechner nicht mehr. Aber Windows Update ist ja bekanntermaßen sehr zuverlässig (https://www.futurezone.de/digital-life/article535935/nicht-installieren-neues-windows-update-legt-viele-computer-lahm.html) und macht niemals Fehler, also können Windows-User sich entspannt zurück lehnen. Das Update kommt auch zwangsweise und soll sich weder blockieren noch widerrufen lassen. Auch auf Maschinen, bei denen Secure Boot nicht aktiv ist.

Am Thread-Titel brauchen wir also nichts zu ändern, der stimmt noch. Nur der Grund hat sich etwas geändert.

Was bedeutet das für die User?


Wer Bitlocker einsetzt, sollte auf jeden Fall den Wiederherstellungsschlüssel sichern, denn Bitlocker reagiert gerne verschnupft, wenn man am BIOS rumspielt (wie MS es vorhat). Man beachte, dass Bitlocker manchmal aktiv ist, ohne dass man das selbst angestoßen hat.
Wer einen Dual-Boot nutzt, muss besonders aufpassen, denn die Umstellung wird vermutlich das jeweils andere System lahm legen. Denn das Update aktualisiert natürlich nur den Bootloader der laufenden Installation und nicht den eventueller anderer.
Vorsicht ist dann in Zukunft auch angeraten bei den Optionen im BIOS, mit denen sich der Werkszustand wiederherstellen lässt. Wenn dabei die neuen Zertifikate gelöscht werden, startet der Rechner auch nicht mehr.

[Lookbehind]

Ich freu mich schon, wenn ich in 5 Jahren doch mal wieder auf die Idee kommen sollte, ein Windows auf meinem Rechner installieren zu wollen, und das nicht geht, weil der zum fraglichen Zeitpunkt kein Windows hatte, und somit die Zertifikate nicht passen. UEFI is schon ein toller Standard. So simpel und einfach und robust. Da kann quasi nie irgendwas schief gehen. Ich bin so froh, dass wir das umgestellt haben. §ugly

[Nobbi Habogs]

Ich bin allerdings auch froh um die neuen Funktionen

[foobar]

Ich bin allerdings auch froh um die neuen Funktionen

Zum Beispiel?

[Nobbi Habogs]

Zum Beispiel?
Viel detailliertere Lüftersteuerung und Hardware Monitoring, Treiber können vor Betriebssystemstart geladen werden (z.B. USB3), Resize BAR, Boot-Medium über 2 TB und das wichtigste: Es sieht besser aus §ugly

[Lookbehind]

Viel detailliertere Lüftersteuerung


Is ne implementierungsfrage und wäre auch mit klassischem BIOS oder CoreBoot möglich gewesen. Hat halt nur früher keinen interessiert.



und Hardware Monitoring,


Ist allgemein eine Funktion der Hardware, dass sie diese Informationen bereit stellt. War auch früher schon möglich und nicht unüblich. Monitoring-Software ist nun wahrlich keine neue Erfindung.



Treiber können vor Betriebssystemstart geladen werden (z.B. USB3),


Seit wann lädt das UEFI irgendwelche Treiber? Wäre für mich noch ein Grund das nicht zu benutzen!
Oder geht es dir nur darum, dass dein USB-3 Stick schon als bootbares Medium erkannt wird, damit du dein OS schneller installieren kannst? Auch dafür bedarf es keinem UEFI.



Resize BAR,


Hier bin ich offen gestanden wirklich nicht ganz sicher, ob das UEFI da eine Rolle spielt. Eigentlich™ ist das eher eine Frage von CPU, RAM, Board und Steckkarte (in den meisten Fällen wohl die Grafikkarte). Aber ich will nicht ausschließen, dass das UEFI hier einen kleinen Teil beisteuert. Dafür kenne ich ReBAR noch nicht gut genug.



Boot-Medium über 2 TB


Funktionierte definitiv schon mit nem klassischen BIOS. Darfst halt keins von 1995 nehmen, da hatte man das noch nicht vorgesehen.



und das wichtigste: Es sieht besser aus §ugly

Auch das ist eine reine Implementierungsfrage. Die (grafische) Oberfläche hat ja nix damit zu tun, was da unten drunter für ein System werkelt und wie der Boot-Mechanismus abläuft.

Es gäbe ja wirkliche Vorteile von UEFI gegenüber einem klassischen BIOS. Auch wenn viele davon sich auch anders hätten umsetzen lassen ... gibt ja nicht bloß BIOS und UEFI ... aber dann wirds echt viel hier.
Das hier angesprochene SecureBoot zum Beispiel. Man kann darüber diskutieren WEM das eigentlich Sicherheit bringt, und wovor, und ob die Implementierung eine gute Idee war. Aber an sich ist das ein Feature, welches du im klassischen BIOS nicht finden wirst.
Oder die Grundidee, dass das UEFI das System direkt startet, statt einfach auf den Boot-Sektor der Platte zu verweisen. Hätte man das richtig implementiert, hätten wir uns sowas wie den Bootloader sparen können. ... hätte!
...

[Homerclon]

ReBAR ist eine PCIe-Funktion, sollte daher auch mit klassischem BIOS funktionieren.

[foobar]

Nobbi hat recht in dem Sinne, dass zusammen mit der Umstellung auf UEFI auch einige Verbesserungen und Komfortelemente in die Firmwares eingeflossen sind. Wenn man eine moderne UEFI-Firmware mit einem BIOS von vor 20 Jahren vergleicht, sieht man schon einige Verbesserungen. Zumindest teilweise. Es gibt auch UEFI-Firmwares, die genauso aussehen und sich bedienen wie ein altes PC-BIOS aus den 90ern. Aber das ist so oder so eine Korrelation, keine Kausalität. Die Technik hat sich halt weiter entwickelt, aber das heißt nicht, dass andere Pfade nicht besser gewesen wären. Ja klar, gegenüber einem Ford Modell T ist ein Trabant 601 ein gewaltiger technologischer Fortschritt. Das heißt aber nicht, dass der Trabbi ein gutes Auto gewesen wäre – selbst, wenn man die Maßstäbe seiner Zeit anlegt.

Das bereits erwähnte Coreboot ist ein gutes Beispiel. Findet sich z.B. auf Chromebooks und einigen ausgewählten PCs, die auf Hochsicherheitsanwendungen getrimmt sind (bspw. von der deutschen Firma NitroKey). Da startet das OS innerhalb von 3 Sekunden. Und wen juckt’s, ob man in diesen 3 Sekunden kein Polynom 8ten Grades für die Lüfterkurve einstellen kann? Man braucht kein buntes Setup, weil die Firmware praktisch nichts macht. Sie initialisiert nur gerade so viel Hardware, dass das Betriebssystem booten kann und übergibt dem dann die Kontrolle. Alle weiteren Einstellungen erledigt man dann dort in der bekannten Umgebung. Der Quellcode liegt offen und jeder kann gucken, was er macht. Und wer mit seiner Firmware nicht zufrieden ist, kann sich seine eigene kompilieren und einspielen.

UEFI ist dagegen eine Black Box, in die man keine Einblicke hat. Im Grunde ein verstecktes zweites Betriebssystem, über das man keine Kontrolle hat. Und wem es nicht gefällt, wie der Mainboard-Hersteller die UEFI-Firmware implementiert... tja, der ist eben angeschissen.