Ab 2026 sollen ja die Zertifikate abgelaufen sein, und Rechner mit Secure Boot nicht mehr hochfahren.
Jetzt habe ich im UEFI-Bios nachgesehen und stelle fest, dass dort noch die "alten" Zertifikate mit Angabe "2011" sind.
Die Prozedur zur Aktualisierung ist für mich derart undurchschaubar, dass ich hier einmal nachfragen möchte, was wohl das Beste wäre.
Also:
Microsoft schlägt vor: Erst einmal BIOS UEFI updaten.
Möchte ich machen, aber dann verlangt die Herstellerseiteninfo ein vollständiges Motherboard Firmware Update.
Geht da irgendetwas durch Fehleingabe schief, läßt sich das Motherboard nicht mehr ansprechen -> Schrott.
Dann heißt es bei Microsoft:
Updates für das BIOS und die Zertifikate werden schrittweise mit den monatlichen Updates und Patches ausgerollt. Man müsse nur ein Update von Februar 2024 schon besitzen, dann würde die BIOS-Updatefunktion automatisch laufen.
Letzte Möglichkeit wäre natürlich Secure boot zu disablen.
Microsoft sagt: Dann bekommt man keine Sicherheitsupdates mehr.
Also.
Was soll man tun?
Abwarten und Tee trinken ist wohl keine Option.
ciao
gustav
P.S.: Momentan steht in Ereignisanzeige zwar noch
"...Der Softwareschutzdienst hat die Überprüfung des Lizenzierungsstatus abgeschlossen..."
Aber spätestens ab 2026 kommt der große Crash, dem ich meinerseits vorbeugen möchte.
Mein Win10 sagt, dein Zeug ist zu alt für Win11! Ich nutze weiter meinen
Verbrenner ;-)
Klar.
Neues Motherboard Pro Z690-A DDR4
AMI BIOS 1.10.13.12.2021
viel zu alt, klar.
Win 11 24H2 Build:26100.4946
Update: (KB5063878) (26100.4946)
Alles in den Müll.
Also, die Angst vor einem Bios-Update-Fehlschlag ist ein Risiko, das man eingehen kann.
Wenn es einen gibt sollte man den einspielen, alleine schon für Sicherheitslückenaktualität und Microcodeupdates bzgl. Energieverbrauch und teilweise auch Brandgefahr.
Das geht normal nicht schief, außer man hat Stromausfall in dem Moment, und moderne Boards haben eh ein Reservebios, das im Fehlerfall einspringt.
Den Secureboot abzuschalten ist die beste Wahl wenn man Angst vor dem Fail des Signaturupdates hat, der ist dann nämlich egal.
Allerdings gibt es mittlerweile Software die nur auf Securebootgeräten läuft...
Das solche PCs allerdings keine Updates mehr bekämen wäre mir neu.
Ich hab das auf allen Rechnern deaktiviert (schließlich soll auch Windows nicht am PC oder BIOS rumpfuschen) und habe die aktuellste Variante laufen.
Letzte Möglichkeit wäre natürlich Secure boot zu disablen.
Microsoft sagt: Dann bekommt man keine Sicherheitsupdates mehr.
Da bin ich mal gespannt. Ob Microsoft wohl vorhat, die digitale Autonomie weltweit zu fördern, indem unzählige Ämter völlig überraschend die Fähigkeit zu Windows-Updates verlieren? :)
Den Secureboot abzuschalten ist die beste Wahl wenn man Angst vor dem
Fail des Signaturupdates hat. der ist dann nämlich egal.
Zweimal nein. Das Update kommt (bzw. kam schon) automatisch, und dann funktioniert es eben oder nicht. Das Abschalten von Secure Boot hat überhaupt keinen Einfluss auf irgendwelche Updates.
Und nein, es ist nicht egal, wenn der BIOS-Inhalt wg. einem schiefgegangenem Update fehlerhaft ist.
Du erinnerst dich, wie überraschend für Ämter, Bundestage und wohl auch einige Unternehmen das sehr lange angekündigte Ende von Windows 7 kam? Mit heftigen Zusatzkosten für Verlängerung des Supports.
Das Update kommt (bzw. kam schon) automatisch, und dann
funktioniert es eben oder nicht.
Da war ja auch noch was mit "es ist kein Platz mehr im Flash, ach scheiß drauf, dann hat jeder Rechner halt zufällig andere Schlüssel drin, was solls".
Ja, da gings um zurückgezogene/gesperrte Bootloader, aber das Windows einfach so die Schlüssel tauscht wird nicht überall funktionieren.
Wäre das erste Mal das MS Software schreibt, die überall 100% klappt.
dann würde die BIOS-Updatefunktion
automatisch laufen.
Ich würd niemals irgend einer Software erlauben, an meinem Bios rum zu pfuschen...
Oder haftet Microsoft, wenn der Rechner im Anschluss daran nicht mehr hoch fährt?
Oder haftet Microsoft, wenn der Rechner im Anschluss daran nicht mehr
hoch fährt?
Durch Updates gebrickte Rechner kommen gelegentlich vor. Mir spukt in diesem Zusammenhang Fujitsu im Kopf herum. Kann vorkommen, dass der Hersteller oder Händler konziliant wird, wenn nicht Oma Müller vor der Tür steht, sondern ein grösseres Unternehmen.
Wie Händler, Hersteller und Microsoft das dann untereinander klären, kriegt man üblicherweise nicht mit.
Das geht normal nicht schief, außer man hat Stromausfall in dem Moment,
und moderne Boards haben eh ein Reservebios, das im Fehlerfall
einspringt.
Ist das so? Auch wenn ich nicht mehr die Hand am Puls habe, so lese ich doch immer noch, aber dass die Rechner quasi ein "Basis-Bios" haben, ist mir neu.
Du erinnerst dich, wie überraschend für Ämter, Bundestage und wohl auch
einige Unternehmen das sehr lange angekündigte Ende von Windows 7 kam?
Mit heftigen Zusatzkosten für Verlängerung des Supports.
Aber ja. Und ich verstand auch nicht, weshalb "Ämter, Bundestage und wohl auch einige Unternehmen" es nicht geschafft haben, rechtzeitig auf eine neue Version umzusteigen. Tja, wer weiß, vielleicht ist der verlängerte Support sogar ökonomischer als eine Neuanschaffung und Aktualisierung des Systems?
Aber um eine veraltete Windows-Version geht es hier nicht.
Aber um eine veraltete Windows-Version geht es hier nicht.
Sondern um Termine, die so lange ignoriert werden, bis dies akut in den Hintern kneift. Ob es dabei um die Version von Windows geht, oder die Version der Boot-Zertifikate, ist sekundär. Und in beiden Fällen geht es um Systeme, die nicht mehr aktualisiert werden können.
Aber vielleicht ist es diesmal nur ein laues Lüftchen, das in der Breite keine Rolle spielt.
Ja ist mittlerweile üblich, mein Laptop hat auch ein Recovery Bios. T14 Gen 1 mit Ryzen 5 von Lenovo, geht das Update schief startet automatisch das Recovery und nach wenigen Minuten ist man bereits wieder mit der älteren Version arbeitsbereit.
Aber vielleicht ist es diesmal nur ein laues Lüftchen, das in der Breite
keine Rolle spielt.
Wenn die im Hintergrund laufenden Update-Prozesse die neuen Keys nicht ins Rechner-Flash bekommt, ist der Rechner nach dem Ablaufdatum gebrickt, falls Secure Boot aktiv ist.
Da das Thema aber seit Monaten durch alle einschlägigen Medien incl. Youtube geistert, sollte jeder einigermaßen helle Admin das auf dem Schirm haben.
Durch Updates gebrickte Rechner kommen gelegentlich vor. Mir spukt in
diesem Zusammenhang Fujitsu im Kopf herum.
Yep. Gestern bei mir auch.
Das Fuji Notebook reagiert mit:
Hatte dreimal versucht "wiederholen":
Gelblich unterlegtes PopUp:
"Neuinstallation des Windows nötig..."
Komisch: sfc scannow hat keine Fehler gefunden.
Was ist da dann an Systemkomponenten kaputt?
Und ja, Secure Boot ist enabled.
Und, der Rechner läuft ja noch.
Dasselbe Update klappte aber beim "großen" Desktop PC.
Der Win 10 Rechner ließ sich gestern auch (noch) problemlos updaten.
Wenn die im Hintergrund laufenden Update-Prozesse die neuen Keys nicht
ins Rechner-Flash bekommt, ist der Rechner nach dem Ablaufdatum
gebrickt, falls Secure Boot aktiv ist.
So? "Gebrickt" bedeutet in diesen Kontext, dass der Rechner wie ein Ziegelstein (brick) ist: Ein handliches, totes Stück Material, mit dem man praktisch nichts mehr anfangen kann, außer es in die Hand zu nehmen und wegzuwerfen. AFAIK wurde dieser Begriff ursprünglich für Handys benutzt, bei denen das Rooten nicht geklappt hat.
In unserem Fall schaltet man einfach Secure Boot ab, dann läuft der Rechner wieder. Er wird also nicht zum Brick.
Mainboards sind inzwischen wirklich sicher, was Bios-Updates angeht.
Diese tief verwurzelte Urangst aus 486er-Zeiten kann man hinter sich lassen.
Bei manchen Boards lässt sich das Bios sogar ohne CPU, ohne gesteckten RAM und mit ausgeschaltetem Netzteil (Also nur 5Vsb) flashen. USB-Stick in den richtigen Port, Knöpfchen drücken, warten bis das Blinken aufhört, fertig.
Auch wenn ich nicht mehr die Hand am Puls habe, so lese ich
doch immer noch, aber dass die Rechner quasi ein "Basis-Bios" haben, ist
mir neu.
Gibt verschiedenes, schon seit Jahrzehnten.
Automatisches Dualboot, manuelles (mit Brücke, mit 5x Abwürgen, und und und), Hilfsbiosdings mit "Stick mit bestimmter Datei in bestimmten Port stecken".
Und normalerweise sind Biosupdates heute a) Windowsprogramme und b) beinahe tägliches Geschäft, nicht wie früher Boot-irgendwasse mit Kommandozeile.
Lenovo updated das BIOS über den normalen Lenovo-Updater, beinah jeden Monat.
Mittlerweile mal ein bootfähiges Win11 Medium auf USB erstellt, für alle Fälle. Noch die Keys ausgelesen mit dem dafür empfohlenen Tool und diese aufgeschrieben.
Dann nochmal ins Bios geschaut. (Bios Setup Utility, Fujitsu E5411)
Also doch ein Win10 auf Win11 gepimpt. Und auch da die "alten 2011-er"
Zertifikate.
Werde Tipp befolgen und Secure Boot abschalten im BIOS.
Mal sehen, wie sich das in Zukunft entwickelt, ob die Redmonter sich noch etwas Intelligenteres einfallen lassen.
ciao
gustav
P.S.: Mein Virenscanner sucht zunächst Systembereiche, dann Rootkits, dann erst rast der Virenscanner los.
Was soll Secure Boot überhaupt Besseres vollbringen als es solchige Virenscanner-Programme schon von sich aus tun?
SB soll verhindern, das die Mühle solche Dateien überhaupt erst startet, während der Scanner mit Glück irgendwann später herausfindet, dass das ja wohl nicht da hin gehört.
Letzte Möglichkeit wäre natürlich Secure boot zu disablen.
Microsoft sagt: Dann bekommt man keine Sicherheitsupdates mehr.
Also.
Was soll man tun?
Abwarten und Tee trinken ist wohl keine Option.
Was soll man tun?
Abwarten und Tee trinken ist wohl keine Option.
Du brauchst gar nichts zu tun. Mache deine Arbeit, und lass Windows seine Updates machen. Wenn du so eine alte Gurke hast, die Windows nicht mehr updaten mag, dann lass sie ohne Updates weiterlaufen. Kein Grund hier Panik zu verbreiten.
Ist doch blödes Clickbaiting. Ich brauche Admin Rechte um in meinem Windows/System32/config Ordner eine Datei zu erstellen oder zu löschen.
Probiere mal "rm -rf /" mit root Rechten auf deinem Linux, -rf steht für really fast...
Du brauchst gar nichts zu tun. Mache deine Arbeit, und lass Windows
seine Updates machen.
Gestern habe ich auch ein Update bekommen. Da stand das mit den
Zertifikaten.
Ich denke auch, dass man selbst nicht aktiv werden muss.
Glaube ich nicht.
Laut Problembericht ist da etwas vermurkst.
Beim anderen Rechner funktionierte es ja.
Manueller Installationsversuch bleibt im Status "Initialisierung" stehen.
Dann nochmal ins Bios geschaut. (Bios Setup Utility, Fujitsu E5411)
Also doch ein Win10 auf Win11 gepimpt. Und auch da die "alten 2011-er"
Zertifikate.
Wie gründlich hast du denn nachgesehen? Die alten sind natürlich noch drin, die lassen sich gar nicht löschen bzw. überschreiben, in dieser BIOS-eigenen Sperre liegt ja gerade die Sicherheit.
Es geht darum, dass zusätzlich die neuen drin sind. Das ist aber AFAIK kaum ein Problem. Die hat inzwischen wahrscheinlich ohnehin jeder in seinem BIOS.
ABER: Es gibt im BIOS eine zweite Datenbank, in der eingetragen wird, welche auf jeden Fall ungültig sind, selbst wenn sie noch nicht abgelaufen sind. Auch diese Einträge lassen sich nicht löschen bzw. überschreiben. Und hier liegt das eigentliche Problem: Manche alten BIOS-Versionen haben nicht genug Platz dafür, weil – was so vor 10+ Jahren nicht bedacht war – es mehr als 100 sein können.
SB soll verhindern, das die Mühle solche Dateien überhaupt erst startet,
während der Scanner mit Glück irgendwann später herausfindet, dass das
ja wohl nicht da hin gehört.
Wenn die Zertifikate in einem Jahr nicht geupdated werden wird auch nichts großartiges passieren.
Windoof wird einfache weiterlaufen, mit marginal weniger Sicherheit.
Aber spätestens ab 2026 kommt der große Crash, dem ich meinerseits
vorbeugen möchte.
Ich habe, seit ca. 3 Jahren, ein "HP Elite Dragonfly 13.5 inch G3 Notebook PC/897F, BIOS U90 Ver. 01.14.00 01/13/2025", auf dem Devuan installiert ist. Kein Windows.
Firmware Updates bekomme ich über fwupd / lvfs, und die kommen auch in KDE Discover automatisch.
Jetzt hab ich mal nachgesehen, wie es um die Secure Boot Zertifikate steht, aber die scheinen noch nicht aktualisiert worden zu sein...
Da werde ich wohl doch noch versuchen müssen, eigene Keys zu hinterlegen. Letztes mal hatte ich das aufgegeben, weil es mir zu riskant war. Könnte ja wenn es blöd kommt plötzlich gar nichts mehr gehen...
Einfach einen per UEFI zur DB hinzufügen geht bei dem Laptop leider nicht einfach so...
Man kann darüber wohl die Keys / DBs irgendwie ersetzen, aber das scheint recht riskant zu sein, man muss das irgendwie alles am richtigen Ort ablegen usw. Also auch nicht einfacher, als das selbe unter Linux zu machen.
Bei der Anleitung oben sieht es so aus, als ob die KEK Keys updates mit dem PK signiert sind, und die DB Updates mit einem der KEK keys, ist das richtig? Und der PK Key kann nur ersetzt werden, wenn vorher im Bios alle Keys gelöscht wurden?
Ich muss mal ausprobieren, ob das bei meinem Laptop geht... Schade, das es keinen weg zu geben scheint, einfach einen eigenen Key zur DB hinzuzufügen, und ich da wohl alles ersetzen muss. Das kann momentan wohl nur HP und MS, weil nur die per default Keys im KEK drin haben.
Ich nehme an, den HP Key muss ich wieder rein nehmen, der wird sicher für HPs eigene UEFI Firmware gebraucht?
MS Keys kann ich dann ja entfernen, weil ich Grub & Kernel dann selber signieren kann.
Ich hab es mittlerweile hin bekommen, meine eigenen Keys zu hinterlegen. War ein ziemlicher Krampf. Als ich den PK Key hinterlegen wollte, stand dort als Grösse -4, und ich musste erst den PC Rebooten, bevor ich das machen konnte, und dann ist in der Anleitung auch noch die falsche Datei angegeben... (man braucht die .auth Datei, nicht die .esl Datei, für den PK. Oder vermutlich könnte man auch mit -k den Key nochmal angeben, wenn man die .esl nimmt).
Zuerst hatte ich noch die Debian CA in die db mit reingetan. Die shim.efi war aber mit dem MS key signiert. Also habe ich das shim-signed Paket deinstalliert, und ein "grub-install --uefi-secure-boot" gemacht . Dann ist grub gestartet, ist ja von debian signiert. Aber ohne den shim lässt es mich den linux kernel nicht laden wenn secure boot eingeschalten ist. Fehlermeldung war irgendwas wegen "shim lock" nicht vorhanden... "grub-install" mit "--disable-shim-lock" ging nicht, ist in debian kaputt. Also shim-signed wieder installiert. Jetzt hab ich den halt signiert:
Dann den debian key wieder entfernt. War auch mühsam. Erst waren die efivars alle immutable, dann ging die .auth Datei nicht (efi-updatevar -f db.auth db) (eventuell schon zu alt?), aber mit (efi-updatevar -e -f db.esl -k master.key db) ging es dann...
(Ich habe in PK, KEK, und db den selben Key rein getan. Normalerweise nimmt man da unterschiedliche, brauch ich aber nicht wirklich, und ist einfacher).
--
Um zum Thema zurückzukommen, so könnte man natürlich auch die neuen Windows Keys manuell ins uefi bringen, wenn man sich das antun will.
Wie gründlich hast du denn nachgesehen? Die alten sind natürlich noch
drin, die lassen sich gar nicht löschen bzw. überschreiben, in dieser
BIOS-eigenen Sperre liegt ja gerade die Sicherheit.
Habe ich gerade gemacht, das geht. Man kann sowohl zur DB hinzufügen, als auch die ganze EFI variable, in der die gespeichert ist, ersetzen, sofern man den KEK Key hat.
ie lassen sich gar nicht löschen bzw. überschreiben, in dieser
BIOS-eigenen Sperre liegt ja gerade die Sicherheit.
Habe ich gerade gemacht, das geht. Man kann sowohl zur DB hinzufügen,
als auch die ganze EFI variable, in der die gespeichert ist, ersetzen,
sofern man den KEK Key hat.
Den privaten Teil des KEK hast du aber nicht, der steht ja nicht in der Firmware.
Wenn ich dich richtig verstanden habe, hast du dich als OEM-Hersteller deines PC verkleidet und u. a. einen eigenen PK eingetragen. Damit besitzt du dann aber keinen Rechner von der Art, mit der sich Microsoft beschäftigt. Mit so einem PC wirst du nichts an Software laden können, das aus einer Quelle stammt, die deinen PK nicht kennt.
Also ja, du kannst überschreiben, aber es nützt de facto nichts.
Klar, wenn du das BIOS eines PC komplett selbst schreibst, dann kannst du dabei alle Sperren weglassen. Die UEFI-Sicherheit gilt für solche Rechner natürlich nicht – aber das ist hier ja nicht der Diskussionspunkt.
PK ist der Hauptkey der Maschine. Per default ist da das Zertifikat vom PC Hersteller.
In der KEK sind die Keys von denen, die die DB Updaten können müssen. Normalerweise einer vom Hersteller, und einer von MS. Wenn man den privaten Teil des PK hat, kann man den KEK ändern. (Ob man das auch kann wenn man den privaten Teil eines der KEK schlüssel hat, bin ich mir gerade nicht sicher).
In der DB sind dann die Keys, mit dem die Anwendungen signiert sind. Da reicht der private Teil von einem Key aus der KEK, um den zu ändern. EFI Firmware, Bootloader, usw. Die können dann manchmal auch noch eigenen Keystores haben, wenn sie selbst was nachladen.
Den privaten Teil des KEK hast du aber nicht, der steht ja nicht in der
Firmware.
Ja, am Anfang stand ich nicht in der KEK. Darum hab ich am Anfang alle Keys im Bios gelöscht (eine so vorgesehene Funktion), damit es mich neue eintragen lässt. Aber jetzt habe ich einen Key in der KEK, in der db, und den PK Key.
Wenn ich dich richtig verstanden habe, hast du dich als OEM-Hersteller
deines PC verkleidet und u. a. einen eigenen PK eingetragen.
Ich hab mich im PK eingetragen. Das ist aber nicht sich "als OEM-Hersteller verkleiden". Das ist mein PC, ich bin Besitzer und Eigentümer, also ist es nur richtig, das ich den Master Key dafür habe.
Damit besitzt du dann aber keinen Rechner von der Art, mit der sich Microsoft
beschäftigt. Mit so einem PC wirst du nichts an Software laden können,
das aus einer Quelle stammt, die deinen PK nicht kennt.
Doch. Der Software, inklusive Windows selbst, hat es egal zu sein, was in der PK und der KEK steht. Wenn die Anwendungen mit einem der Keys aus der db signiert sind, ist alles ok.
Wenn man MS oder dem OEM noch erlauben will, die db zu verändern, packt man deren Key noch in die KEK. Für was anderes wird der nicht gebraucht.
Das ist ein gewöhnliches Root of Trust System, ähnlich wie es das auch bei Webseiten mit SSL gibt. (Und auch da ist es den Webseiten egal, was für ein Key da genutzt wird, das prüft da der Browser, nicht die Webseite).
Also ja, du kannst überschreiben, aber es nützt de facto nichts.
Doch. Ich könnte die 2023 MS Keys in die db packen, und könnte dann Windows auch nach 2026 mit Secure Boot starten.
Klar, wenn du das BIOS eines PC komplett selbst schreibst, dann kannst
du dabei alle Sperren weglassen. Die UEFI-Sicherheit gilt für solche
Rechner natürlich nicht – aber das ist hier ja nicht der
Diskussionspunkt.
Am Bios habe ich gar nichts geändert. Ich habe lediglich per UEFI, im setup mode, über die dafür vorgesehenen UEFI Schnittstellen, die PK, KEK, und db Keys neu gesetzt.
Und dann hab ich, auch normal per UEFI, mit eingeschaltetem Secure Boot, die db keys nochmal ersetzt, und dabei einen Key entfernt. Das zeigt, dass MS und der Hersteller, auch Keys entfernen könnten, denn wie ich nun, haben/hatten die in der KEK ja auch einen Key.
Wo ist denn die Sicherheit des Secureboot-Systems, wenn jeder einfach so ins Bios gehen kann und da "seine" Keys eintragen kann?
Du schreibst, du da jetzt eigene Keys drin hast, d.h. du kannst jetzt trotz Secureboot eigene Software laufen lassen. Die kann dann ja wieder alles machen, also eben auch Malware sein.
Letztendlich müsste ja nur ein "Update" deine Keys eintragen und schon läuft dein "Superspymalwarevirusrootkit" auch auf meinem PC....
Das kann doch nicht der Sinn des Ganzen sein?
Warum hast du solche Schlüssel, bzw. wie einfach/günstig ist es die zu bekommen?
Weil letztendlich ist das was du da gemacht hast ja genau das was vor dem Stichtag passieren muss: einmal alle Keys durchtauschen.
Wenn man da drauf achtet das es auch mit alten W10-Installationen geht, hat man ja eigentlich das "jeden PC wieder flottmachen"-Dings.
Wo ist denn die Sicherheit des Secureboot-Systems, wenn jeder einfach so
ins Bios gehen kann und da "seine" Keys eintragen kann?
Ganz einfach: nicht jeder sitzt physisch vor dem PC, und kann so ins Bios rein. Und wenn man die eigenen Keys mal drin hat, hat man seine privat Keys idealerweise an einem sicheren Ort abgelegt, wo andere & Malware nicht einfach so dran kommen. Mit dem kann man dann nämlich die Keys auch updaten, ohne ins Bios gehen zu müssen.
Du schreibst, du da jetzt eigene Keys drin hast, d.h. du kannst jetzt
trotz Secureboot eigene Software laufen lassen. Die kann dann ja wieder
alles machen, also eben auch Malware sein.
Ja klar, man muss halt aufpassen, was man mit seinen Keys signiert. Die Malware selbst kennt deinen Key nicht.
Ein Gerät vor Malware zu schützen ist schon schön und gut, aber vor Dir sollte DEIN gerät nicht "geschützt" werden.
Letztendlich müsste ja nur ein "Update" deine Keys eintragen und schon
läuft dein "Superspymalwarevirusrootkit" auch auf meinem PC....
Das kann doch nicht der Sinn des Ganzen sein?
Wenn du bei dir meinen Key einträgst, und ich signiere ein "Superspymalwarevirusrootkit", ja, dann läuft das bei dir.
Ist auch bei den OEM und MS Keys, die per drauf sind, nicht anders. Wenn MS oder der OEM dann ein "Superspymalwarevirusrootkit" signiert, läuft das.
Aber wenn du selbst einen Key erstellst, und den im Bios hinterlegst, den hab ich nicht.
Ausserdem, MS hat vermutlich schon versehentlich einige Rootkits signiert, wobei ich mit meinem Key nur gerade die ein zwei Anwendung signiere, die ich halt selbst für den Systemstart brauche.
Warum hast du solche Schlüssel, bzw. wie einfach/günstig ist es die zu
bekommen?
Die kann sich jeder selbst erstellen.
PS: Ich weiss das macht fast keiner, aber wenn ihr euren Laptop ausleiht, damit Reist, oder andere da ran kommen, solltet ihr auch ein Bios Passwort setzen, damit nicht jeder einfach so ein Rootkit installieren könnte :3
Wenn du bei dir meinen Key einträgst, und ich signiere ein
"Superspymalwarevirusrootkit", ja, dann läuft das bei dir.
Wir reden aber hier doch von dem Schutz durch die ganze UEFI-Mimik bzw. davon, dass der angeblich nicht existiert, weil jeder Dackel Daten in der Firmware manipulieren kann.
Deine Malware müsste also bei mir vorab heimlich deinen Key eintragen. Kann sie das?
(Zertifikate) Die kann sich jeder selbst erstellen.
15 Zeilen Powershell für das RootCert und 15 Zeilen für das davon abgeleitete. Die von Powershell benutzte .NET-Library bringt alles Nötige mit.
Wenn du bei dir meinen Key einträgst, und ich signiere ein
"Superspymalwarevirusrootkit", ja, dann läuft das bei dir.
Wir reden aber hier doch von dem Schutz durch die ganze UEFI-Mimik bzw.
davon, dass der angeblich nicht existiert, weil jeder Dackel Daten in
der Firmware manipulieren kann.
Deine Malware müsste also bei mir vorab heimlich deinen Key eintragen.
Kann sie das?
Ganz einfach: nicht jeder sitzt physisch vor dem PC, und kann so ins
Bios rein.
Wenn der Zugriffsschutz der ist, das ich vor deiner Maschine sitzen muss, dann glaub ich dir das kaum.
Updates für BIOS, Microcode und anderen Kram aus dem Flashchip sind auch Windowsprogramme.
Sicher das dieser Weg wirklich nur über den "mit Tastendruck ins BIOS und dann eine Datei laden" geht?
Ein Gerät vor Malware zu schützen ist schon schön und gut, aber vor Dir
sollte DEIN gerät nicht "geschützt" werden.
Da bin ich bei dir. Meine Handys sind auch alle mit Root, damit da nur Software läuft mit der ich konform gehe.
Mir ging es um den hypothetischen Fall, das du bösartig wärst, und meine Annahme stimmt, das so ein "Update" wie du ihn gemacht hast, ohne Benutzereingriff (maximal "dieses Programm muss als Administrator ausgeführt werden") funktioniert.
Also
Daniel schreibt einen Bootmassakervirus
Signiert den
Aktualisiert das UEFI-Secureboot
Secureboot startet Bootmassakervirus weil "Secureboot ist an und alle Zertifikate sind Grün"
Daniel greift nach der Weltherrschaft
Irgendwie scheint die ganze Lästerei über das totgepfuschte Secureboot und das man das nie irgendwie richtigpfuschen kann wahr zu sein.
Ist auch bei den OEM und MS Keys, die per drauf sind, nicht anders.
Nuja, denen muss man halt vertrauen. Irgendjemand muss ja der Grundlegendste Zertifizierer sein, dem alle glauben.
Daher wundert mich das man so einfach sich selber zum Zertgott machen kann.
Mir fällt auf, das diese "Sicherheit" wie so oft eher Probleme für den User bringt, aber dem Gerätehersteller und Softwarekonzern alle Freiheiten einräumt.
Der Benutzer hingegen steht nach dem Willen der Großen mit Pech in 30 Sekunden ohne alles da.
Mir fällt auf, das diese "Sicherheit" wie so oft eher Probleme für den
User bringt, aber dem Gerätehersteller und Softwarekonzern alle
Freiheiten einräumt.
Der Benutzer hingegen steht nach dem Willen der Großen mit Pech in 30
Sekunden ohne alles da.
Sehe ich auch so und zusätzlich räumen die Hersteller sich -wenn man dabei nicht genau hinschaut und wer guckt schon in die Updates rein- immer mehr und heimlich Rechte ein, die du ihnen vorher nicht gewährt hattest.
Beitrag "Re: Windows 11 Zertifikate"
Kurzer Zwischenbericht:
Nach ca. 2 Stunden Reparatur-Windows-Installation ist das besagte Notebook auf dem neusten Stand. Im Bios wurde Secure Boot vorher disabled.
Das beanstandete KB ist nicht im Updateverlauf zu finden.
Ist wohl schon drin bei der Reparaturinstallation.
Da steht nur: Update 24H2.
Vom Windows Old mit 16,1 GB datenträgerbereinigt.
Danke an die zahlreichen Kommentare, die einem den Horizont öffnen.
So wusste ich nicht, dass die BIOS-Update deswegen nicht gehen, weil beispielsweise unter Umständen nur maximal 100 Einträge für die Verweise auf DBs vorgesehen waren.
Trotzdem wird dieses Thema noch bestimmt für weitere Diskussionen sorgen.
Auf meinem Gigabyte "Brett" ist das BIOS doppelt gespeichert. Geht was
schief kann ich immer noch das alte einspielen...
Das dachte vor Jahren ein Azubi auch, hat leider nicht geholfen, weil ein Virus einiges verbogen hatte im BIOS und dann die CPU ganz böses Fieber bekam. MB= Schrott.
Das dachte vor Jahren ein Azubi auch, hat leider nicht geholfen
Dann war aber nicht das BIOS betroffen von dem Virus. Bei Dual-Bios Boards sind einer von beiden Flash Speicher IMMER physisch (mit einem Schiebeschalter) vom Strom und Bus getrennt.
Der Virus hat damals im BIOS eingegriffen und die CPU überhitzt. Dann nützt auch das schönste 2. BIOS nix mehr, wenn die CPU es nicht vertragen hat und Leiterzüge vom MB weggebrannt sind. Das Böse lauert überall.
Wenn Du denkst es geht nicht mehr, kommt irgendwo ein Lichtlein her.
ciao
gustav
P.S.: Ich hatte den Rechner aber "vorbereitet" u.a. mit
bootmgfw_2023.eft
Habe im Bios nachgeschaut. Da kann man keinen Screenshot von machen.
Die anderen 2023 Zertifikate sind auch drin.
War wohl eine Extrawurst.".. Wir stellen Ihnen ein Update für Sicheren Start zur Verfügung, wollen Sie es installieren..?
Hab es hinterher auch nicht im Updateverlauf gefunden.
Ereignisprotokoll System Ereignis 1808
"...UpdateType: Windows UEFI CA 2023 (DB), Option ROM CA 2023 (DB), 3P UEFI CA 2023 (DB), KEK 2023, Boot Manager (2023)
Weitere Informationen finden Sie unter https://go.microsoft.com/fwlink/?linkid=2301018..."
Die Sicherheitsfunktion, die das Booten von Schadsoftware verhindern soll, befindet sich im UEFI-BIOS und wirkt – sofern nicht vom Nutzer abgeschaltet – bei jedem Booten jedes Betriebssystems. Andernfalls würde sie logischerweise wirkungslos sein.
Das bedeutet, dass man auch für Linux Zertifikate braucht. Die Zertifikate, die Microsoft für Nicht-Windows-Systeme bietet, laufen am selben Tag ab wie die für Windows-Systeme.
Wer sehen will, welche Zertifikate er auf seinem Rechner hat, dem empfehlen die Profis das Tool
Check UEFI PK, KEK, DB and DBX.cmd
zu finden unter
https://github.com/cjee21/Check-UEFISecureBootVariables
Dort README.md lesen.
(Alte Zertifikate: Jahreszahl 2011, neue Zertifikate: Jahreszahl 2023)
