Am 02.09.22 tauchte die folgende „Nachricht“ im Heise Newsticker als Heise+-Artikel auf:
Bootloader-Signaturen per Update zurückgezogen: Microsoft bootet Linux aus
Was ist überhaupt geschehen:
Microsoft hat mit einem Windows-Update die Liste der gültigen Secureboot-Schlüssel für bestimmte Bootloader gesperrt. Dadurch starten Systeme diese Bootloader nicht mehr, wenn Secureboot aktiviert ist. Davon betroffen ist auch eine Grub-Version mit schwerwiegenden Sicherheitslücken:
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass2021
Der wichtigste Aspekt an der Sicherheitslücke ist, dass Canonical und andere Distributoren die Signatur selbst zurückgezogen haben (Stichwort DBX/Revocation Database) und Microsoft dass nur mit einem Windows-Update für Windows selbst nachgeholt hat.
Zurück zur verlinkten Heise+-Nachricht:
Das perfide an diesem Artikel ist, dass der wichtigste Inhalt der Nachricht am Ende des Anrisstextes steht und die meisten Kommentatoren der Nachricht diesen Teil gar nicht mehr wahrgenommen haben:
Seither verhindert UEFI Secure Boot, dass etliche Linux-Distributionen booten. So konnten wir bei Redaktionsschluss das noch immer aktuelle Ubuntu 20.04 LTS und auch Manjaro Linux nicht mehr installieren – außer, man schaltet Secure Boot im BIOS-Setup ab. Auch Live-Linux-Systeme wie etwa Desinfec’t booteten nicht mehr auf PCs, bei denen zuvor das Windows-Update automatisch eingespielt wurde.
https://www.heise.de/hintergrund/Bootloader-Signaturen-per-Update-zurueckgezogen-Microsoft-bootet-Linux-aus-7250544.html
Wenn man diesen Teil genau liest, sieht man sehr schnell, dass es sich nicht um Linux-Installationen handelt, sondern einzig um allein um Installationsmedien bzw. Live-Systeme.
Es gibt genau zwei (!) Konstellationen, die von den gesperrten Bootloadern überhaupt betroffen sein können:
- Die erwähnten Bootmedien, welche noch die alte unsichere Grub-Version enthalten. Dazu gehört Ubuntu 20.04.5 und älter (Korrigiert, siehe auch Kommanter von Xino). Ubuntu 22.04 ist davon nicht betroffen.
- Dualboot-Installationen, bei denen die Linux-Installationen schon seit mindestens einem Jahr (!) keine Updates mehr erhalten haben. Ubuntu hat z.B. das Sicherheitsupdate für Grub im Mai 2021 ausgeliefert.
Der Druckartikel in der c’t beschreibt dann auch genau diese zwei Szenarien, wobei nur letzteres ein größeres Problem darstellt, dass sich relativ schnell lösen lässt (SecureBoot abschalten, Linux-Installation updaten, SecureBoot wieder einschalten).
Das interessante ist, dass es nur genau ein Tech-Magazin weltweit gab, welches sich diesem Thema überhaupt angenommen hat, nämlich Heises c’t. In allen anderen Tech-Medien tauchte dieses „brisante“ Thema überhaupt nicht auf.
Wie kommt also Heise überhaupt darauf eine solche Nachricht zu veröffentlichen? Das lässt sich ziemlich einfach beantworten:
Heises desinfec’t Live-Linux-Virenscanner basiert in der aktuellen Version auf Ubuntu 20.04 und dadurch auf einer ISO-Datei, welche die verwundbare Version von Grub enthält. Wahrscheinlich haben ein paar Leser und/oder einzelne Heise-Mitarbeiter auf den Umstand hingewiesen, dass desinfec’t nicht mehr bootet und man hat aus diesem Umstand dann schnell einen Artikel gebacken.
Bevor jetzt hier Kommentare landen, die sich über SecureBoot und Microsoft im Allgemeinen aufregen wollen:
Man kann über den Sinn und Zweck von SecureBoot mehr als nur streiten. Nur ist die „Schuld“ diesmal definitiv nicht bei Microsoft zu suchen, da die Firma nur ihren „Pflichten“ nachgekommen ist, unsichere Bootloader zu sperren.
Mich persönlich stört viel mehr, dass Heise aus diesem „Nicht-Thema“ einen Artikel bastelt und ihn mit einer reißerischen Überschrift versehen hinter einer Paywall versteckt um möglichst viele Heise+-Abos zu verkaufen. Dazu kommt noch die Tatsache, dass es Heise dann auch nicht für notwendig hält die Clickbait-Überschrift zu korrigieren.
Dieser Artikel war es dann auch, der mich dazu gebracht hat, mein c’t-Abo zu kündigen.
GNU/Linux.ch versucht auch Kapital daraus zu schlagen in dem es auf die Geschehnise nicht eingeht, künstlich aufregt und für den Verkauf auf veralteten und überteuerten Mist verlinkt.
Vielen Dank für die Aufklärung. Mich hat das sehr verwirrt und verunsichert, da ich dual boote und gelegentlich Windows verwende. Ich war mir nicht sicher, ob das Windows Update einfach noch nicht installiert wurde und warum meine Systeme weiterliefen.
Und was ist, wenn der PC mit Secure Boot nicht Ubuntu 20.04.5 vom USB-Stick startet und nur „Secure Boot Violation“ angezeigt wird? Versucht der PC dann etwas zu laden, was gesperrt ist?
Du hast recht. Die ISO-Datei bootet nicht auf einem, mit Windows aktualisierten Rechner:
https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1990326
Canonical hat es bei der aktuellen 20.04.5-ISO versäumt Shim zu aktualisieren. Ich werde den Artikel entsprechend anpassen. Wenn man aber SecureBoot zur Installation deaktiviert und nach der Installation direkt wieder aktiviert, funktioniert das System, da das installierte System eine passende Shim-Datei und Grub enthält.
Danke für den Link. Auf zwei Rechnern startet der USB-Stick mit Ubuntu 20.04.5 nicht, auf einem weiteren startet Ubuntu 20.04.5 aber einwandfrei.
Der eine Rechner, wo Ubuntu startet, hat vor kurzem ein Update des UEFI mit „Change the default setting of Secure Boot“ erhalten. Ansonsten ist das Setup gleich. Auf allen ein Ubuntu und Debian, sowie Windows 10 mit gleichen Updates und Secure Boot an.
Warum startet der eine Rechner dennoch den Ubuntu 20.04.5 USB-Stick mit Secure Boot an und die beiden anderen nicht, hat jemand eine Idee?
Wie kann das denn so unterschiedlich sein?