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
foofoobar
Rear Admiral
- Registriert
- Dez. 2011
- Beiträge
- 5.501
@xexex Die Windows Admins bei mir in der Firma haben Fremdbrowser im Griff, insbesondere weil die Browser von M$ bzgl. des Speicherverbrauchs eher schlecht sind.
Als ich mal just4fun Edge für eine Anwendung genutzt habe die ich zu benutzen habe, hat es wohl den Terminalserver fast gesprengt den ich gerade genutzt habe, und das nur mit einem Bruchteil der Tabs die ich normalerweise in dieser Anwendung nutze.
Als ich mal just4fun Edge für eine Anwendung genutzt habe die ich zu benutzen habe, hat es wohl den Terminalserver fast gesprengt den ich gerade genutzt habe, und das nur mit einem Bruchteil der Tabs die ich normalerweise in dieser Anwendung nutze.
Kann man LUKS mit Windows nutzen!? Mhhh...foofoobar schrieb:
Und natürlich kann man mit anderen System andere Sachen nutzen die wieder andere Schwachstellen und Angriffsvektoren aufweisen. Das ist unbestritten. Aber darum ging es doch überhaupt nicht.
Dein "LUKS ..., ohne secure-foo und TPM" schützt dich eben bspw. absolut gar nicht davor, wenn etwas an deinem Wissen vorbei sich im Bootprozess einklinkt und damit die Verschlüsslung potentiell aushebelt oder bspw. Keyeingaben mitließt und in die große Weite Welt schickt. Es schützt dich auch nicht davor, dass Schadsoftware von dir unbewusst mit deinem Account und den Rechten die dein Account erlangen kann, Dinge am Bootprozess verändert und sich damit zumindest längerfristig in das System oder noch schlimmer in die Firmware der Hardware einnisstet.
Am Ende ist das natürlich alles eine Frage des Ziels - sprich was will man, was will der Nutzer, was will der Hersteller und was soll hinten bei rum kommen. MMn ist es aber absolut unbestritten, dass den Boot Prozess abzusichern definitiv eine Idee ist, die sinnvoll ist. Und genau das macht Secure Boot. Mit vielen Vorzügen ggü. keiner Nutzung von Secure Boot. Aber eben auch ein paar Nachteilen. Wer verzichten kann, soll es gern tun. Einen echten Zwang gibt es meines Wissens aktuell nicht. Auch bei Windows nicht. -> Windows funktioniert generell auch ohne Secure Boot.
- Registriert
- Mai 2020
- Beiträge
- 1.405
Definitiv. Eine Chain of Trust die direkt bei der Hardware beginnt ist sinnvoll.fdsonne schrieb:
Die Kontroverse beginnt aber nicht bei der Technologie, sondern dort, wo sie zu einem Machtinstrument werden kann. Microsoft ist de facto der Schlüsselverwalter der Welt geworden, da Microsoft auch den PC-Markt dominiert. Dadurch kann MS indirekt entscheiden, welche Software auf deiner Hardware als sicher gilt. Dann werden auch Hürden für Alternativen eingebaut.
Das ist im Grunde die große Kritik dahinter und endet darin, dass der Käufer zwar die Hardware besitzt, nicht aber die Hoheit darüber hat, was darauf erlaubt ist, ohne tiefergreifende und oft komplizierte Änderungen vorzunehmen.
Echte Sicherheit entsteht durch Transparenz und Wahlfreiheit, nicht durch Abhängigkeit von einem einzigen Konzern aus Redmond.
Noch nicht. Mal schauen, wie lange das so bleibt.fdsonne schrieb:
andy_m4
Admiral
- Registriert
- Aug. 2015
- Beiträge
- 9.024
Ja. Das Ding ist, der potentielle Schaden ist ja schon alleine dadurch sehr groß, das Malware Dein System infiziert hat. Auch ohne sich in den Boot-Prozess einschmuggeln zu können.fdsonne schrieb:
Secure-Boot soll ja vor allem vor dem Szenario schützen, das ein Angreifer Deine Hardware in die Finger bekommt. Allerdings bietet Zughang zur Hardware vielfältige Angriffsmöglichkeiten und Secure-Boot sichert lediglich eine davon ab.
Daher ist die Antwort auf diese Bedrohung auch nicht, Secure-Boot einzuschalten, sondern seine Hardware nicht in unbefugte Hände zu geben.
Man kann ja von mir aus trotzdem sagen, das Secure-Boot ein nützliches Feature ist. Aber es ist eben nicht so nützlich, wie oft dargestellt.
Vor allem aber hilft es bei der Mehrzahl der Angriffe denen man so ausgesetzt ist gar nicht.
Von daher wäre das jetzt - mal zurückhaltend ausgedrückt - nicht meine oberste Priorität, wenn es darum geht, einen PC abzusichern.
Naja. Immerhin ist Secure-Boot optional. Und Du darfst eigene Keys im UEFI hinterlegen.ShiftC schrieb:
Zudem kriegen alternative Systeme wie Linux ja sogar die Möglichkeit sich mit dem Microsoft-Schlüssel signieren zu lassen.
Ich würde da auch nicht nur ein Auge auf Microsoft haben, sondern vor allem auf Hersteller die das UEFI so implementieren, das Abschaltbarkeit und Support von eigenen Keys eben nicht (oder nicht einfach zugänglich) unterstützt wird.
- Registriert
- Mai 2020
- Beiträge
- 1.405
Wie gesagt, noch. Außerdem trifft das erstmal nur auf den Desktop-PC zu. Bei ARM-Geräten (Windows-Tablets usw.) ist SecureBoot verriegelt.andy_m4 schrieb:
Das klingt nach Großzügigkeit, betont aber auch hier die Abhängigkeit. Ein unabhängiges OS braucht den Segen eines kommerziellen Riesen, um auf Hardware zu funktionieren, die Microsoft gar nicht gehört, nur weil auf der Hardware standardmäßig das Microsoft UEFI CA hinterlegt ist.andy_m4 schrieb:
Da gehe ich voll mit dir. MS liefert die Richtlinien, aber die Hersteller bauen die Hardware und das UEFI und das Key-Management ist de facto ein Expertenprivileg und gleicht schon fast einer OP am offenen Herzen.andy_m4 schrieb:
Am Ende das Tages gilt für uns, dass Microsoft es geschafft hat, dass ihr Schlüssel der Standard-Türöffner der Welt ist. Wer diesen Türöffner nicht will, muss zum Experten werden. Die Hoheit ist nur theoretisch vorhanden, wird in der Praxis aber durch enorme Hürden erschwert.
Es würde mich nicht wundern, wenn MS irgendwann mal so weit geht und sagt, dass OEMs nur dann ihr Windows-Logo auf ihre Hardware packen dürfen, wenn auf der HW ausschließlich ihre CA hinterlegt wird.
Bei mir hatte nur mein Arbeits-PC das Zertifikat-Update bekommen. Meine ZBOX und mein Gaming PC nicht. Hatte aber eine Anleitung gefunden, wie man das Update manuell anstoßen kann, ohne Windows Update. Jetzt ist es auch auf den anderen PCs aktualisiert. Ich wusste ja nicht, ob das dann dort auch noch per Update kommt oder durch etwas blockiert wird.
andy_m4
Admiral
- Registriert
- Aug. 2015
- Beiträge
- 9.024
Es geht hier ja weniger ums generelle funktionieren, sondern ums vereinfachen.ShiftC schrieb:
Aber ja. In der Tendenz hast Du natürlich Recht.
Wobei man sagen muss, das Microsoft ja inzwischen ihr Hauptgeschäft mit der Cloud macht.ShiftC schrieb:
Für die ist es gar nicht mehr so entscheidend was da auf der Client-Hardware läuft, solange die Azure-Cloud benutzt wird.
Auf der anderen Seite schielt man sicher auch gern mal in Richtung Apple und ist auch ein bisschen neidisch auf deren geschlossenes Ökosystem. :-)
Das mag ja so sein, wenn man Microsoft dort als Problem sieht - aber ist das wirklich das Kernproblem? Es gibt keinen Zwang, dass es Microsoft zu sein hat. Wenn einem das alles nicht zusagt, die eigene PKI mit einem eigenen PK und Microsoft ist raus. Machen andere doch auch.ShiftC schrieb:
Was btw. technisch noch dazu kommt - ein UEFI im Setup Mode frisst jedes! vorgesetzte Zertifikat. Letztlich ist das hier einfach nur ein Henne/Ei Thema. Denn wenn man ein Gerät mit Windows vorinstalliert kauft oder ein Gerät, was vom Hersteller mit Windows vorgesehen ist, dann gibt es halt in aller Regel die Microsoft Keys im UEFI hinterlegt, weil Microsoft diese Windows per Default Auslieferung an Bedingungen knüpft. Das ist ihr gutes Recht als Lieferant der Software und letztlich auch eine freiwillige Entscheidung des Herstellers, das so zu tätigen.. Das ist also das Resultat, aber eben nicht der Grund für deine Kontroverse!
Die Annahme einer potentiellen Ausnutzung des Konstrukts ist mMn allein dahingehend nicht gegeben, weil Microsoft hier überhaupt nicht in der Position ist, das durchsetzen zu können. Klar könnten sie heute mit einem Update sozusagen einfach so die ganzen Signaturen ungültig machen und hart in die Gerät rein bringen. ABER den PK können sie eben nicht ändern. Es wäre technsich ein leichtes für die OEMs Updates bereit zu stellen, die wiederum Microsoft da raus kicken. Mit dem Resultat, dass dann im Zweifel kein Windows mehr laufen würde. Oder wenn man es nicht Schwarz/Weiss sieht, dass der User sich für Windows oder Alternativen entscheiden könnte. So nach dem Motto, aktiviere die non MS Firmware oder die MS Firmware. Bei ersterem läuft alles außer Windows, bei letzterem nichts außer Windows. DAS ist die Designentscheidung des OEMs. (mal von Surface oder MS Branded Hardware abgesehen)
Wie gesagt, von der technischen Betrachtungsweise ist das durchaus ein Teil der Kritik - aber warum wird hier Microsoft als Buhmann vors Loch geschoben wenn der eigentlichen Problem-Auslöser der OEM ist, der sich exakt dafür entschieden hat?ShiftC schrieb:
Der Kernkritikpunkt der UEFI Problematik ist nicht der KEK oder der die Zertifikate die in der Datenbank stehen sondern der PK. Der Besitzer des PK Schlüssels ist der einzige der definieren kann, was und wie dort rein geladen wird. Während der Produktion initial bzw. mit/nach Updates.
Microsoft kommt als Schlüsselbesitzer des KEK und der anderen CAs hingegen erst später im Prozess ins Spiel, weil die mit dem Schlüssel weitere Schlüssel rein laden dürfen (was eine UEFI Design Komponente ist) - Sicherheitstechnisch darf das nur geändert werden wenn du den Schlüssel hast. Microsoft hat den KEK private Key und kann deswegen die Zertifikate erneuern, aber eben nur überall dort, wo der KEK schon drin ist.
Das ist halt auch so eine Sache. Sicherheit entsteht nicht durch Transparanz und Wahlfreiheit. Das gibt dir exakt gar kein mehr an Sicherheit. Sicherheit bekommt man wenn der Prozess nicht irgendwie von außen aushebelbar ist. Dass Finden von Fehlern in der Umsetzung kann durch Transparenz und Einsichtmöglichkeiten erleichtert werden bzw. das Finden kann erschwert werden, wenn man nicht rein gucken kann. Das steht außer Frage, aber ob das transparente und selbst gewählte Konstrukt "sicher" ist, ist überhaupt nicht davon abhängig ob man wählen kann oder rein gucken kann...ShiftC schrieb:
Das ist doch am Ende erstmal nur eine Definition des Angriffsvektors. Es muss ja keine Infektion während des Betriebs erfolgen. Technisch wäre eine modifizierte Firmware, die Schadcode enthält, bspw. auch denkbar. Mit Secure Boot geht das bspw. nicht. Da diese Firmware eben nicht mit den passenden Schlüsseln signiert wäre.andy_m4 schrieb:
Technisch wie gesagt, kannst du das soweit spinnen, deine eigene PKI zu betreiben. Dann bist nur du der Jenige, der signieren kann. Nur du hast den Schlüssel und idealerweise kennt auch Niemand außer dir den Schlüssel. Dann ist halt kein Reinkommen. Ohne den Prozess hingegen wäre das aber ohne Aufwand möglich.
Das ist sicher richtig, dass man damit den Angriffsvektor verringert. Aber das ist eben nur ein Teil der potentiellen Angriffsvektoren. Man löse sich bitte einfach davon, dass da nur privat Hanseln mit Single PCs und Turnschuh-Admin Prinzip sitzen. Das ganze Konstrukt ist doch nicht dafür erfunden, dass Gretchen Müller mit ihrem PC irgend einen Mehrwert hat - das zielt in erster Linie auf Firmen mit Compliance Anforderungen ab.andy_m4 schrieb:
Der Root auf dem PC ist in aller Regel eben auch der Account, der technisch die Firmware mit allem drum und dran modifizieren darf. Das WILL man aber im Firmenumfeld unter gewissen Compliance Anforderungen nicht.
Oder noch ein anderes Beispiel - nimm Sony und die Playstation. Die wollen halt nicht, dass du die Hardware für deine Software benutzt. Oder ggf. zusatz Software in ihr System rein bringst. Also was macht man? Man dongelt das zu.
Aber ja, du hast zweifelsfrei recht. Secure Boot ist nicht das Allheilmittel. Zu sagen, dass es keinen Sinn hat, ist aber faktisch auch nicht richtig. Es nicht zu nutzen öffnet einen (weiteren) Vektor und macht einen eben Angreifbar. Nur warum das nicht schließen, wenn es so einfach geht?
So funktionieren Sicherheitskonzepte nicht. Es geht dabei NIE!! darum, dass ein Teil der Kette alles abdeckt. Das ist immer ein größeres Gebilde wo verschiedene Kettenglieder Zusammen eine Sicherheitskette bilden. Und ja, ein gebrochenes Kettenglied kann die Kette reißen lassen - das stimmt wohl. Aber das funktioniert eben andersrum genau so. Wer es eben zulässt, am Sicherheitskonzept (sinnbildlich die Kette) den Bolzenschneider anzusetzen, muss halt damit rechnen, dass die Kette reißt. Den Bootprozess dann eben nicht abzusichern ist so ein Beispiel.andy_m4 schrieb:
Das muss ja nicht. Real praktisch ist es doch hier konkret eh Microsoft die das pushen. Das heißt, rein technisch kann sich der Mirosoft Nutzer doch zurück lehnen und hat kein Problem. Und der nicht Microsoft Nutzer importiert einfach die Zertifikate und gut ist (wenn Secure Boot aktiv) oder lässt es, weil er Secure Boot eh nicht nutzen will. Ggf. bekommen manche Boards noch via Firmware Update die Zertifikate rein gebügelt.andy_m4 schrieb:
Der entscheidende Faktor ist der PK in dem Zusammenhang. Ein UEFI ohne PK ist im Setup Mode und frisst jede Zertifikate die man ihm gibt. Ein UEFI im User Mode hat einen PK und spielt nach den Regeln dieses. Der Besitzer des privaten Schlüssels des PK ist der OEM/Vendor des Boards/des Gerätes. Mit Mircrosoft hat das alles nur am Rande zu tun.andy_m4 schrieb:
Dem Marktanteil zur Folge, wollen das offenbar viele der Nutzer von Client Systemen. Ja... Keine Ahnung was du uns hier mitteilen willst. Aber wahrscheinlich hast du dich einfach nur im Thread geirrt. Hier geht es um Windows Updates. JFYI.foofoobar schrieb:
andy_m4
Admiral
- Registriert
- Aug. 2015
- Beiträge
- 9.024
Ich grätsche hier mal rein.fdsonne schrieb:
Weil ich bei Deinen ganzen Einwürfen stark das Gefühl hab, das Du an dem vorbei redest was ich gesagt habe bzw. mir auch Dinge unterstellst, die ich gar nicht behauptet habe.
Deshalb ist das Beispiel auch ganz gut.
Weil meine Aussage war ja nicht:
"Secure Boot bringt nix man über Weg XYZ ja trotzdem Schaden am System anrichten kann".
Ich hab ja selbst versucht klar zu machen, das Secure-Boot eben nur vor bestimmten Dingen schützt. Und das man dann halt gucken muss, für welche Angriffsszenarien es etwas bringt. Und dann ggf. gar nicht unbedingt der Schwerpunkt darauf liegen muss.
Und klar kann man jetzt sagen: Ok. Ich mache es aber trotzdem.
Nur würde das dem widersprechen was ich sage? Nee. Nicht.
Und das zieht sich durch alles, wo Du mir geantwortet hast. Und da stellt sich halt schon die Frage, was Deine Einwürfe sollen. Sind das Ergänzungen? Oder widersprichst Du mir? Aber wenn Du mir widersprichst, bist Du Dir dann auch sicher, das Du mich überhaupt verstanden hast?
- Registriert
- Mai 2020
- Beiträge
- 1.405
Etwas transparentes und wählbares ist natürlich nicht sicher nur aufgrund dieser Eigenschaften.fdsonne schrieb:
Ganz genau. Im Wort "außen" muss sinngemäß auch der Hersteller des geschlossenen Systems stecken. Falls nicht, driftet das Thema in Richtung Vertrauen. Sicherheit hat mehrere Facetten.fdsonne schrieb:
Geschlossene Systeme erschweren das Finden von Schwachstellen und Hintertüren. Das suggeriert nur, dass es sicherer wäre, nur kommt hier genau der gravierende Unterschied, dass der Hersteller eines geschlossenen Systems seine eigenen Aushebelungen einbauen kann, ohne dass du es siehst, bemerkst und findest. Wollen ja nicht so tun, als hätte so etwas noch niemand auf der Welt erlebt.
MS wird nicht pauschal als Buhmann vors Loch geschoben, sondern wird automatisch zur Gefahr, weil die Verhältnisse es über die Zeit so weit gebracht haben, dass sie eine sehr große Macht besitzen und damit großes Potential haben, Dinge zu tun, die gegen die Interessen der Endnutzer sind.fdsonne schrieb:
Von diesem ewigen, transatlantischen Blindvertrauen wachen die ersten deutschen ja glücklicherweise ein bisschen auf. Besser spät als nie und besser einige als gar keine. Ersetze den MS-Konzern mit irgendeinem Konzern aus China und die wären schon längst die ersten, die vor irgendwelche Löcher geschoben würden.
Wenn mal alle Stricke reißen, interessiert es auch MS nicht, dass andere vorher ein hohes Vertrauen hatten oder das irgendwelche Verträge geschlossen wurden. Am Ende sind das nur Wörter auf Blätter.
Ich möchte hier nicht den Teufel an die Wand malen, sondern das Thema nur aus neutraler Sicht bewerten. Wenn wir ehrlich und aufrichtig bleiben, sollte es uns egal sein, wer was abhören, aushebeln, austricksen oder eben sperren kann. Der Fokus sollte nicht auf WER, sondern auf OB liegen. Niemand sollte es dürfen!
Aktuell reicht ein DBX Update um das mit Secure Boot startende System bootunfähig zu machen. Microsoft schreibt aktuell vor, dass Secure Boot vorhanden sein muss, erlaubt aber (noch), dass der Nutzer es im UEFI deaktivieren kann und gewiss wird das irgendwann abgeändert. Ist ja bereits bei den Windows-Tablets längst der Fall. Die OEMs spielen hier mit, weil sie sonst das Windows-Logo nicht draufpacken können und ohne Windows-Logo verkaufen sich die Geräte schlecht, da die ganze Welt überwiegend Windows nutzt.
Ich habe die Anleitung hier befolgt:XXYYZZ99 schrieb:
https://pureinfotech.com/windows-11-secure-boot-certificates-expiring-june-2026/
Erst über das Terminal (als Admin) den Flag setzen:
Code:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /fDanach den Task für das Update ausführen
Code:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"Dann nur noch rebooten. Man sagte eigentlich 2 mal neustarten, damit es greift, bei mir hats nach dem ersten Mal geklappt.
Mit
Code:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'Aber zur Sicherheit auf der Seite schauen, da gibts noch Anmerkungen falls man z.B. Bitlocker aktiviert hat.
Vielen Dank @CrazyWolf - hat funktioniert!
- Registriert
- Feb. 2009
- Beiträge
- 265
Vielen Dank auch von mir @CrazyWolf, hat funktioniert.
