[English]Microsoft "liebt" Linux, wie man so hört. Es gibt das WSL (Windows Subsystem for Linux) unter Windows 10/11 – und die Microsoft Leute arbeiten auch mit der Linux-Community zusammen. Aber unter dem Strich tun sich die Jungs und Mädels aus Redmond schwer, ihr Zeugs, was sie da per Update rausdonnern, sauber zu testen. Schlägt bereits bei Windows fehl, führt bei Linux aber zur Katastrophe.
Anzeige
Die vergangenen Tage gab es zwei Baustellen: Ein Azure-Ausfall auf Grund eines verbuggten Updates kickte Ubuntu VMs aus dem Rennen. Und unter Windows hat das DBX-Update für den Secure Boot faktisch Linux lahm gelegt, weil kein Booten mehr möglich war. Hier ein kurzer Überblick über die beiden Fälle.
Systemd-Update kickt Ubuntu VMs aus Azure
Die Kollegen von Bleeping Computer hatten das Thema Ende August 2022 in diesem Beitrag aufgegriffen. Zum 29./30. August 2022 wurden Kunden, die virtuelle Maschinen (VMs) unter Microsoft Azure betrieben, von einem Ausfall ihrer Ubuntu 18.04-Gäste überrascht. Ein fehlerhaftes systemd-Update verursachte Probleme und die Ubuntu-Gäste wurden offline genommen.
Der Ausfall begann neun Stunden vorher, gegen 06:00 UTC, nachdem betroffene Kunden systemd auf Version 237-3ubuntu10.54 aktualisiert hatten und ihre virtuellen Maschinen mit Ubuntu DNS-Fehler aufwiesen. Auf den betroffenen Systemen war keine DNS-Auflöserung mehr verfügbar. Laut Microsofts Ausführungen auf der Azure-Statusseite betraf dieses DNS-Problem nur VMs mit Ubuntu 18.04 (Bionic Beaver).
Starting at approximately 06:00 UTC on 30 Aug 2022, a number of customers running Ubuntu 18.04 (bionic) VMs recently upgraded to systemd version 237-3ubuntu10.54 reported experiencing DNS errors when trying to access their resources. Reports of this issue are confined to this single Ubuntu version.
Laut der Azure-Statusseite waren weltweit die Dienste Azure Kubernetes Service (AKS), Azure Monitor, Azure Sentinel, Azure Container Apps und weitere von diesem Ausfall betroffen.
Anzeige
Azure Status, Source: Bleeping Computer
Eine mögliche Lösung für diesen systemd-Fehler, die einen Wechsel zu einem Fallback-DNS-Server und einen Neustart erfordert, ist auf der Launchpad-Software-Kollaborationsplattform von Canonical verfügbar. Wer nicht betroffen war, braucht aber nichts zu unternehmen – und es tangierte nur die eine, oben genannte Ubuntu-Version.
DBX-Update KB5012170 kickt Linux-Boot ins Abseits
Das zum 9. August 2022 von Microsoft freigegebene Update KB5012170 verursacht bei einigen Windows-Systemen böse Probleme bei der Installation und mit Bitlocker. Ich hatte im Blog-Beitrag Update KB5012170 für Secure Boot DBX verursacht Bitlocker-Probleme darüber berichtet. Was an mir vorbei ging, war, dass das DBX-Update für Secure Boot auch massive Kollateralschäden verursacht. Blog-Leser Bolko wies im Diskussionsbereich mit folgendem Kommentar auf diesen Sachverhalt hin (danke dafür).
Mit dem August-Patch KB5012170 hat Microsoft über 100 Linux Distributionen sabotiert, weil deren Bootloader-Signaturen aus der Secure Boot Datenbank im UEFI gelöscht wurden, so dass man Linux nicht mehr mit secure boot booten kann.
Darunter sind auch so bekannte und weit verbreitete Distributionen wie ubuntu 20.04 LTS oder Manjaro.
Ist so eine Form von Computersabotage nicht illegal, nur weil Microsoft der Täter ist?
Bolko wies auf den Artikel Bootloader-Signaturen per Update zurückgezogen: Microsoft bootet Linux aus von heise hin (der aber hinter einer Paywall steckt). In Kurzform hat Bolko es aber in seinem Kommentar zusammen gefasst: Die Linux-Bootloader sind nutzlos, weil die Signaturen in der DBX fehlen. Microsoft hat das Update KB5012170 zwar zurückgezogen. Das nutzt den Betroffenen aber nichts, weil die Bootloader-Signaturen weiterhin fehlen. Heise gab an, das noch immer aktuelle Ubuntu 20.04 LTS und auch Manjaro Linux nicht mehr installieren zu können. Selbst Live-Systeme lassen sich nicht mehr booten. Notnagel: Man schaltet Secure Boot im BIOS-Setup ab. Ich schreibe jetzt nicht "einmal mit Profis arbeiten" und erwähne auch nicht, dass immer vor Secure Boot gewarnt wurde.
Aber ich kann mir nicht eine Verlinkung auf einen Blog-Beitrag Warnung vor "Botnetz" Windows 10 … verkneifen. Der Artikel datiert vom 1. Januar 2016 (also kein 1. April) und thematisiert einige Aussagen von Rüdiger Weis. Dieser ist Mathematiker, Kryptograph und promovierter Informatiker, der einen Lehrstuhl für Informatik an der Beuth-Hochschule für Technik in Berlin hält. Und der hat auf dem 32C3 ein vernichtendes Urteil über "Trusted Computing", TPM und Secure Boot gefällt. Seine Aussage aus 2016: Microsoft habe das Ganze nicht im Griff. Untermauert wurde dies durch einige Flops, wie den Versuch Microsofts, ein veraltetes SHA-1-Absicherungsverfahren rauszuwerfen. Bei dem Versuch wurde mal eben der Dual-Boot für Linux zerschossen und die Privateinstellungen der Nutzer ruiniert. Weis sprach seinerzeit von handwerklichen Katastrophen …
Anzeige
Na ganz großes Kino. Da hat Microsoft mal richtig zugelangt. Ich habe damals den Vortrag von Rüdiger gesehen und da graute es mir schon. Dann aber war Microsoft ja so unterwegs, dass immer mehr Absicherungen Scheibchen für Scheibchen gekommen sind. Und mit Windows 11 plötzlich der TPM-Zwang.
Ich meine selbst Androiden haben ihr System so weit abgesichert. Aber an PC's ist das eine ganz andere Hausnummer. Ich weiß noch, wie Rüdiger meinte, dass MS den Linuxern die Signaturen geschenkt hatte. Und dann warnte er vor dem Tag, an dem MS sich anders entscheidet.
Überraschung ^^
Wenn ich das richtig verstehe:
* SecureBoot deaktivieren
* Distro starten
* Distro updaten
* SecureBoot aktivieren
Externe USB-Sticks, und Bootmedien müssen halt erneuert werden.
Somit ist das Signatur-Thema aus meiner Sicht unschön, aber halb so schlimm.
Ich fänds sinnvoll wenn SecureBoot-Only für Betriebsysteme gesetzlich grundsätzlich verboten sein sollte. Der Kunde muss die Wahl behalten ob er SecureBoot verwenden will.
Was mich an der Situation anstinkt, ist das als Secureboot 2011 eingeführt wurde alle gejammert haben, das Linux ausgesperrt wird, weil die Hersteller keine kleinen Signaturgeber in UEFI/BIOS aufnehmen würden (zumal es keine gab/gibt? die für alle OpenSource-Anwendungen offen sind).
Dann wurden die Bootloader (Grub & Co, shim) Secureboot fähig und von Microsoft hat großzügig angeboten, diese zu signieren. Und der Kram wurde abschaltbar gestaltet. Auch da hieß es wieder, aber was wenn MS das nicht mehr macht?
Nun ist es so weit, und die Situation ist immer noch unverändert – es gibt keinen Linux-Signaturgeber für Secureboot, der bei irgend einem Hersteller automatisch mit dabei wäre.
Und dank den Systemanforderungen von Windows 11 wird man Secureboot auch bald nicht mehr abschalten können. Tolle Sache, nach 10 Jahren, und keiner will es gewusst haben.
Ich habe diese Meldung auch auf diversen Seiten nachverfolgt, einen Aufschrei scheint es nicht gegeben zu haben – klar, die 1% Linux Desktop-User haben da auch nicht die Macht. Bemerkenswert finde ich nur, dass vor 10 Jahren das Thema auch bei Windows-Nutzern hochkochte und eine Welle schlug, heute scheint es keinen mehr zu interessieren, dass der Rechner zum Backstein mutiert, z.B. wenn Microsoft sagt dass alte Windows-Versionen auch nicht mehr gehen. Möglich ist das ja schließlich ebenso…
Bis einschliesslich Windows10 bootet jedes Windows-System auch ohne SecureBoot einwandfrei.
Ob Windows11 ohne SecureBoot startet, wenn ein TPM2.0 Chip vorliegt wäre interessant zu wissen.
Ja das tut es, und das muss es auf absehbare zeit auch, du kannst ja nicht mit aktiviertem SecureBoot weder treiber test signing noch kernel debugging aktivieren, und irgendwie müssen die Entwickler ja ihre Treiber entwickelt.
Kann es sein das sich da die Home version irgendwann quer stellt, vieleicht.
Aber die richtigen Versionen wie Enterprise oder Education wird das nicht betreffen.
Oder MSFT macht eine "unsichere" Entwickler Edition welche sich dann alle die wollen an stelle der Home aus einschlägigen quellen besorgen und installieren.
Oder man installiert sich was wie efiguard…
Was Windows macht ist MMN ziemlich egal, das kann man immer umgehen.
Was relevant ist ist was die board Hersteller machen, das sie SecureBoot weiterhin abschaltbar lassen, noch besser die Option drin lassen ein eigenen PK und KEK zu installieren.
Danke für den Einwand – der Plausibel erscheint.
Wenn sich SecureBoot unter Windows11 einfach abstellen lässt, dann wär die SecureBoot/TPM2.0 Hardware-Verpflichtung für Windows11 reine Makulatur.
Dann wird es keine Verpflichtung geben, solang nicht Applikationshersteller zwingend SecureBoot voraussetzen (Denkbar Amazon/Netflix/Spiele).
Manjaro kann jetzt Secure Boot? Soweit ich wusste, nur über Umwege mit eigenen Schlüssel anlegen usw..
Das klingt auch nicht so gut.
Zitat:
"Zu viele unsichere Bootloader
Microsoft hat jedoch zu viele dieser unsicheren Bootloader mit Schlüsseln signiert, die die Redmonder fest im BIOS einbrennen, sodass diese im Secure-Boot-Modus unsichere Komponenten nachladen können. Beispielsweise kann man mit Kasperskys Antivirus CD Grub einfach weitere Module ohne zusätzliche Prüfung unterjubeln."
Quelle: https://www.heise.de/news/DefCon-30-Kritik-an-Microsoft-und-Unsicherheiten-in-UEFI-Secure-Boot-7221728.html
UEFI Secure Boot: Microsoft sperrt unsichere Bootloader per Windows-Update
https://www.heise.de/news/UEFI-Secure-Boot-Microsoft-sperrt-unsichere-Bootloader-per-Windows-Update-7220634.html
Ich bin der Meinung, dass es eine Absicherung geben sollte die man wählen kann. Die Firmware wird immer mehr in den Mittelpunkt rücken, es gab in letzter Zeit einige Rootkits(z.B. CosmicStrand) die genau dort ansetzten.
Im Linux Kernel kann man seit längerem auch einen security_lockdown Modus verwenden, der den Kernel etwas absichert.
Die Lösung ist eigentlich ziemlich einfach, nur das die Industrie diese nicht will, wieso auch immer.
Das UEFI soll ganz ohne vorinstallierte SB Keys daher kommen, und bei einem Factory Reset auch alle gespeicherten Keys löschen.
Wenn man nun ein Betriebssystem installiert kann dieses seine bevorzugten Keys dem UEFI ansagen und beim nächstem Reboot wird der Benutzer von UEFI vor dem Boot gefragt ob er diese Keys übernehmen möchte, hier kann er eben auch schlicht und einfach nein sagen, oder wählen das er nur db und dbx übernähmen möchte aber weder pk noch kek. In welchem Fall Windows sein SB hat aber wen es db und oder dbx updaten will triggert das immer eine Benutzer abfrage beim erstem reboot.
Gut die linux benutezr die jetzt ohne nachzudenken auf "ja" cklicken bekommen ihr linux dennoch gebricked, aber naja nachdenken vor dem "ja", ja?
Ferner müsste SB so implementiert sein das wenn eine Signatur Fehler auftritt das System nicht einfach stupide den Boot verweigert, sondern den Benutzer informiert was genau wieso passiert ist und es dem Benutzer überlässt wie verfahren werden soll.
Also ja einfach ignorieren und ein mal booten, booten und hash in db eintragen, booten hash in db eintragen und den problematischen dbx einrtag löschen.
Das wäre Benutezr freundlich und zu gleich für alle relevanten Szenarien genau so sicher wie das jetzige System.
Man müsste es nur Umsätzen.
Und ja Klaar OEM's die ihre Hardware mit vorinstallierten OS ausliefern dürfen die zum os gehörigen keys auch im UEFI vor einstellen, nur das die Benutzer diese eben auch wieder löschen können müssen.
Es ist eine Idiotie sondergleichen für den Boot eines OS erforderliche Keys im UEFI hard zu coden, davon kann nichts gutes kommen.
> Es ist eine Idiotie sondergleichen ..
Wenn man die Benutzer praktisch entmündigen und die Geräte in Clients für alternativlose Cloud Betriebssysteme mit zentral gesteuerten Apps und Zugang nur über zertifizierten Benutzeraccounts umbauen will, dann macht die Strategie durchaus Sinn.
Ob das jeder Benutzer gut findet, ist ein anderes Thema.
Etwas spät, aber vielleicht hilft es ja noch jemandem.
Ich hatte im Hinterkopf "da war doch was" und habe nun mal nachgeschaut, und richtig: Bei meinem Dell-Desktop kann man mittels BIOS-Einstellung verhindern, dass z.B. Microsoft die Keys per Update verändert. Und glücklicherweise hatte ich das vor 3 Jahren, als ich diese Maschine aufgesetzt hatte, auch so eingestellt :-) Weil ich es einfach seltsam finde, dass ein Betriebssystem das BIOS manipulieren können soll.