News Patchday für Windows 11: Microsoft verteilt neue Secure-Boot-Zertifikate
- Ersteller Andy
- Erstellt am
- Zur News: Patchday für Windows 11: Microsoft verteilt neue Secure-Boot-Zertifikate
kellyfornia
Lt. Junior Grade
- Registriert
- Okt. 2025
- Beiträge
- 321
Da saß das Problem ganz sicher vor dem PC und war nicht Windows 11.Mediendesigner schrieb:
- Registriert
- Juli 2008
- Beiträge
- 7.853
Positive Nachrichten möchte hier keiner lesen 😁WinFan schrieb:
cmdr_nemesis
Ensign
- Registriert
- Aug. 2005
- Beiträge
- 234
Ja ja, das sagte mir die Dozentin auch, "ich habe ganz sicher das richtige Kennwort eingegeben", bis ich ihr bewiesen hatte, dass sie nicht das richtige Kennwort bei der Windows 11 Anmeldung eingegeben hat. Sie hatte nämlich eine Zahl vergessen... als es dann soweit war, hat sie zugegeben, dass sie sich vertan hat. Ich möchte nicht wissen, wie oft es sich hier um ein Layer-8-Problem handelt.Mediendesigner schrieb:
areiland
Admiral
- Registriert
- Apr. 2010
- Beiträge
- 9.993
So ist das nun mal wenn man sich nicht mal in der Lage sieht, von der Pin Eingabe einfach zur Passworteingabe zu wechseln und dann das Passwort einzugeben. Das kann man aber sehr schlecht Windows anlasten, denn das ist eindeutig ein Benutzerproblem.Mediendesigner schrieb:
Unabhängig welchen Wert es hat, wenn es überwunden wurde - es ist und bleibt immer noch ein Mehrwert ggü. gar keiner Verifizierung der am Boot Prozess beteiligten Komponenten.foofoobar schrieb:
Du musst Secure Boot ja nicht nutzen. Der Witz bei deinem Argument ist nur, Kritik über das Verfahren gut und schön - aber ohne hat es gar keine Absicherung dieses Teils des Boot Prozesses. Die Kiste bootet was ihr vorgesetzt wird. Komplett alle "Betriebssysteme" mit wie ohne Lücken und auch inkl. aller "M$ root-kits (vulgo Anti-Cheat)" per default. Erst ein Verfahren wie Secure Boot erlaubt dir als Nutzer doch überhaupt derartige Dinge zu unterbinden. Man MUSS! sich ja nicht Microsoft unterwerfen in dem Fall. Das ganze lässt sich zur aller größten Not mit Aufwand auch selbst betreiben. Selbst signierter PK und eigene PKI bspw.
Es geht dabei gar nicht wirklich um die letzten Komponenten in der Bootkette, sondern viel eher um die ersten. Das System soll gar nicht soweit starten, dass du in der Lage bist, modifizierte Kernel Komponenten zu laden.foofoobar schrieb:
Ich denke es ist vom Gedanken her relativ wichtig sich davon zu lösen, dass hier der Nutzer aktiv das System aushebeln kann, weil er die Rechte hat. Der ganze Kram erschlägt vor allem eher Themen wo der Nutzer keine Möglichkeit (mehr) hat zu verhindern, dass das System andere Komponenten bootet als es vorgesehen sind - weil bspw. der Kram entwendet wurde.
Wenn du mir mein Notebook mopst und da ein UEFI PW verhindert, dass die Settings gedreht werden, TPM verwendet wird um Keys zu speichern, der TPM Tresor via Password nicht im Klartext lesbar ist und gleichzeitig die Boot Order hart auf die interne Disk bzw. den Bootmanager gedreht ist, ohne Boot von externen Medien ala USB, LAN, ... -> dann ist die Kiste nicht von extern auf machbar. Natürlich ist das nur eine Frage der Zeit, weil irgendwann in Jahren, Jahrzehnten oder Jahrhunderten die Technik so weit sein wird, dass via Bruteforce die Disk Encryption ausgehebelt werden kann. Aber bis dahin lässt einen das durchaus sicher schlafen.
Secure Boot ist keine Single Stage Prüfung. Sondern eine Multi-Stage "chain of trust" Architektur. Sprich das läuft nicht mit einer einzelnen Prüfung während des Boot Prozesses und wenn das durch geht, dann läuft der Kram.MaverickM schrieb:
Es gibt mehrere verschiedene Ebenen, von Firmware über Bootloader bis Kernel und Treiber. Und ja, auch die Kernel Signaturen werden dabei geprüft. Das Ding dabei ist viel eher, dass es in der Kette relativ weit hinten passiert und eben über das Hinzufügen von entsprechenden Keys möglich ist, auch selbst signierte Kernel oder Kernel Module zu laden. Das "Problem" dabei ist, dem Admin der Kiste wird hier eben die Möglichkeit gegeben, dass selbst zu signieren.
Das kann man gut oder schlecht finden. Egal wie man es dreht, es hat zumindest Vor- wie auch Nachteile.
In gängigen (vor allem Enduser) Geräten ist Microsoft mit einem KEK und mehreren CA Keys vertreten, sodass ein großer Teil dieser Hardware eben durch das Wohlwollen von Microsoft abgehandelt wird. Das muss man halt so akzeptieren oder man nimmt es selbst in die Hand -> PK Austausch und eigene PKI. Das geht zumindest via Linux natürlich. Bei Windows als OS aber wird das nix.
fdsonne schrieb:
Alles schön und gut, aber darum ging es ja in der ursprünglichen Aussage gar nicht. Dort wurde attestiert, dass Secure Boot für Kernel-Level-Anti-Cheats notwendig bzw. gleichbedeutend wäre. Das hat gar nichts miteinander zu tun.
Das steht doch dort aber gar nicht?MaverickM schrieb:
Da oben steht dass "Secure-Boot per Default Betriebssysteme mit Lücken bootet und M$ root-kits (vulgo Anti-Cheat) per Default zulässt". Das wurde kritisiert...
Darauf hin antwortetest du, dass das gar nix miteinander zu tun hat. Doch, hat es. Der Prozess des Secure Boots sieht auch vor, die Kernel Signaturen sowie Kernel Treiber Signaturen zu prüfen. Aber eben erst in einer späten Phase. Das heißt aber nicht, dass sowas pauschal immer erlaubt ist - der Knackpunkt ist hier, dass Microsoft es zulässt und in der Kette wird eben "vertraut" dass Windows hier korrekt agiert. Wie lang die Kette ist, definiert letztlich die Kette selbst. Technisch wäre es möglich mit einem validen first stage Boot Loader einfach aufzuhören und dann einfach alles danach zu booten. Das ergibt Sicherheitstechnisch aber absolut keinen Sinn. Insofern ist das technisch zwar möglich, praktisch aber so aktuell meines Wissens nach nicht ohne eigenen PK mit eigener PKI möglich.
Versuch doch mal unsignierte Treiber in Windows mit aktivem Secure Boot zu laden
Das wird nicht funktionieren. Es gibt Möglichkeiten diese Sicherheitschecks zu deaktivieren. In aller Regel ist die Kette aber eben aufeinander aufbauend und mit aktiven Secure Boot kommst du eben nicht weit.Man sollte sich aber eben wie ich oben auch schon angedeutet habe, davon lösen, dass das Thema nur aus der Nutzerbrille zu betrachten ist. Am Ende definieren hier externe Parteien eine Trust Kette - und der Nutzer kann dem entweder zustimmen oder eben nicht. Im Fall von Anti-Cheat Treibern im Windows ist das zumindest fragwürdig, ob das so funktionieren sollte. Denn es untergräbt aus Nutzersicht die Sicherheit des Systems definitiv.
Zuletzt bearbeitet:
