Mit Debian 12.5 »Bookworm« haben die Entwickler des Debian-Projekts nach der Veröffentlichung von Debian 12.4 vom Dezember ein weiteres Point-Release 12.5 der aktuellen stabilen Debian-Version 12 veröffentlicht. Zeitgleich erhält auch der Vorgänger Debian 11 »Bullseye« (Oldstable) eine Aktualisierung auf 11.9.
Diese Zwischenveröffentlichungen enthalten wie üblich hauptsächlich Korrekturen für Sicherheitslücken sowie einige Anpassungen für schwerwiegende Probleme. Solche Anpassungen werden in den Point-Releases nur dann vorgenommen, wenn keine Regressionen zu befürchten sind.
Doppeltes Release
Für Debian 12.5 wurden 68 Fehler behoben und die seit dem 4. Dezember 2023 aufgelaufenen 42 Sicherheitsupdates kumuliert. Dabei wurden auch kürzlich bekannt gewordene Sicherheitslücken in der GNU C Bibliothek geschlossen. Der Kernel wurde auf 6.1.76-1 angehoben. Für Debian 11.9 wurden 70 Fehler behoben und es flossen 92 Sicherheitsupdates ein.
Zu beachten ist, dass diese Zwischenveröffentlichungen keine neue Version von Debian 12 darstellt, sondern nur einige der enthaltenen Pakete auffrischen. Es gibt keinen Grund, vorhandene Installationsmedien zu entsorgen, da deren Pakete nach der Installation mithilfe eines aktuellen Debian-Spiegelservers auf den neuesten Stand gebracht werden können.
Aktualisierte Abbilder verfügbar
Anwender, die häufiger Updates einspielen, werden viele der Änderungen bereits erhalten haben. Für Neuinstallationen wurden bereits frische Abbilder als Live-Images und als Installer für Debian 12.5 für die jeweils unterstützten Architekturen bereitgestellt. Bestandsanwender aktualisieren ihre Installationen wie gewohnt über das Paketmanagement per sudo apt update && sudo apt upgrade.
Ich wusste gar nicht, ob ich das nutze.
Mal mit dem oben genannten Befehl getestet, ist das so korrekt?
Das Debian Wiki beschreibt exakt diesen Befehl um heraus zu finden ob das System mittels Secure Boot gebootet hat, oder nicht (musste ich auch erst einmal nachlesen).
Mein Rechner bootet auch ohne Secure Boot, aber ich verstehe das Problem so, dass wir Frank (+ ich) damit nicht aus dem Schneider sind, richtig?
Ich habe auch Shim und das ganze Geraspel installiert und gehe davon aus, dass mein Rechner ebenso anfällig/gefährdet wäre, wie all die anderen Betroffenen oder verstehe ich das falsch?
Interessante Antwort. Bin bis eben davon ausgegangen, das ich nicht davon betroffen bin. Hmm?
Genau hier baue ich auf die Community bzw. denen, die sich besser wie ich (oder wir beide) damit auskennen. Da kannst du mal sehen wie unterschiedlich das Verständnis dazu ist. Vielleicht bin ja auch ich vollkommen falsch unterwegs und du liegtst richtig. Bisher wird kein Rechner mit Secure Boot gestartet von denen die ich im Haushalt betreute (5x mit Debian Boockworm).
Achtung, Halbwissen (da ich shim noch nie benutzt habe): einfach mal
efibootmgrausführen und schauen, ob dort shim oder direkt dein verwendeter Bootloader (bei Debian wohl GRUB?) aufgeführt ist.BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,0002,0003
Boot0000* debian
Boot0001* UEFI:CD/DVD Drive
Boot0002* UEFI:Removable Device
Boot0003* UEFI:Network Device
Damit würde ich sagen das Secure Boot auf meinem Rechner nicht aktiv ist.
Bleibt aber trotzdem die Frage in wie weit mich das vor dem eigentlichen Bug schützt.
Link zum golem Artikel: https://www.golem.de/news/shim-kritische-schwachstelle-gefaehrdet-secure-boot-unter-linux-2402-181956.html
Die Tage wurde auf golem.de von einer “Kritische Schwachstelle gefährdet Secure Boot unter Linux” berichtet. Kann wer sagen, ob ed hierzu schon eine Lösung bzw. Pstch dazu gibt? Ich vermute mal, dass hierzu auch der Boardhersteller ein Firmwareupdate liefern muss. Sehe ich das so richtig? Wird hier vielleicht auch nur etwas gepusht?
Laut den Berichten hat Red Hat ja mit Shim Version 15.8 diese Probleme gepatcht. Von dieser Version ist aber bei Debian oder Ubuntu noch nichts zu sehen. https://tracker.debian.org/pkg/shim
Ich bin jetzt nicht so der Profi, aber müsste dann eine neue Version nicht auch wieder für Secureboot signiert werden? Also das hier ein Update nicht ganz so einfach ist?
Aber schon ungut, wenn da 6 Sicherheitslücken gelistet sind.
Danke für den Link.
Kannst auch direkt hier schaun: https://security-tracker.debian.org/tracker/CVE-2023-40547
secure boot? nutzt das wer unter Linux? Dachte immer, das nutzt eh keiner. Was bringt das bei Linux, ausser teilweise Probleme?
Grosser nachteil ist, das der Anwender keine Kontrolle darueber hat.
Wenn du kein Windows im Dualboot hast kannst du SecureBoot mit Linux wunderbar nutzen.
Einfach eigene Keys enrollen, dann braucht man auch kein Shim 😉
Also mir ging es oben gar nicht um Sinn oder Unsinn von Secureboot, nur habe ich gelesen, dass es z.B. bei u.a. bei Fedora Fedora Probleme bei bestimmten Mainboards mit demm Booten gibt. Zur Lösung wird eine neue Shim benötigt, die dann frisch signiert werden muss.
@Termy: Gibt es irgendwo eine vernünftige Beschreibung wie man die eigenen Keys ausrollt? Das würde mich auch interessieren.
Also eine neue Shim-Version müsste ziemlich sicher auch neu von Microsoft gesigned werden, das würde ich auch so sehen.
Bezüglich Beschreibung ist (wie immer^^) das ArchWiki eine super Anlaufstelle: https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Using_your_own_keys
Dabei stelle ich mir gerade tatsächlich auch die Frage, ob es Distros gibt, die das Ausrollen eigener Schlüssel automatisiert haben?
Jetzt wird es interessant. Wenn es also eine neue Shim Version geben sollte und MS müsste den neu signieren, was passiert dann wenn MS das nicht macht oder erst mit Verzögerung. Wie abhängig bin ich eigentlich mit dem Secure Boot von MS? Ist das eine gute Idee? Lässt sich eine bestehende Installation mit Secure Boot umbiegen? Da poppen gerade ein paar Fragen hoch über die ich mir bisher gar nicht so die Gedanken gemacht habe. Warum auch – funktioniert ja bisher super!
Solange du auf die Microsoft-CA vertraust bist du zu 100% abhängig von Microsoft – richtig erkannt 😉
Eine bestehende Installation sollte sich eigentlich recht problemlos auf eigene Keys umbiegen lassen. Solange du kein Windows im Dual-Boot hast natürlich. Dann wird es nämlich spaßig, das Signieren des Windows-Bootloaders bei Windows-Updates zu automatisieren ^^
Ehrlich gesagt, habe ich mir da noch nie wirklich Gedanken drüber gemacht. Installation mit Secure Boot und gut ist. Das dafür Zertifikate benötigt werden, war mir schon bewusst. Das ich so dermaßen von MS abhängig bin, sicherlich nicht. Ansonsten hätte ich mich anders entschieden. Vielleicht schau ich mir das mal an wie groß der Aufwand ist, eigene Zertifikate auszustellen. Für mich ist aber erst einmal interessant wie Debian damit umgeht und das Problem löst. Ist auch krazz: Ich nutze diese Distribution für Lau und erwarte trotzdem irgendwie, dass das Team eine zeitnahe Lösung findet. Das würde ich für normal von einem Unternehmen erwarten wo ich Geld für das Produkt und den Service zahle. Freiwillige …Respekt und wieder einmal herzlichen Dank an alle freiwilligen die dazu beitragen.
Ja man kann auch Trusted Boot o.a. nehmen wenn man denkt.
Also ich werde mich nicht in irgendwelche Abhaenigkeiten begeben. Ich nutze das Zeugs nicht.
Die Frage, die sich mir bei dem Thema stellt ist, kann wirklich nur Microsoft für Secureboot die Zertifizierung übernehmen oder wäre der Aufwand z.B. für Debian das selbst für sich zu machen, einfach zu groß?
Leider sind ja die Angebote z.B. mit Coreboot noch nicht so breit verfügbar, dass man einfach schnell umstellen kann.
Das Zertifizieren ist nicht das Problem. Aber durch Microsofts bzw Windows’ Marketshare werden die Mainboard/Laptophersteller einen Teufel tun und eine andere CA per default installieren.
Und Microsoft wird einen Teufel tun und den Windows Bootloader für jedes Update bei einer anderen CA zu signieren.