Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Zahlreiche Motherboards von MSI betroffen: Secure Boot ohne Funktion
Eigentlich sollte Secure Boot Nutzer davor schützen, Systeme zu starten, die mit Schadcode verseucht wurden. Jetzt hat ein Sicherheitsforscher herausgefunden, dass besagte Funktion nicht immer den versprochenen Schutz bietet. Im Detail betrifft dies zahlreiche Mainboards des Herstellers MSI. ... weiterlesen
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Es wurde auch nicht ausgehebelt, sondern die defaults sind so gesetzt, dass auch unsignierte Systeme gebootet werden. Man bauscht das aktuell unnötig auf. Vermutung an anderer Stelle war, dass MSI die W11 Voraussetzungen erfüllen will und dennoch standardmäßig alles bootfähig halten möchte.
Dann bootet halt auch jedes Linux ohne das der User fummeln muss und W11 meckert trotzdem nicht.
Ob es sinnvoll ist, das so zu lösen, sei dahingestellt.
MSI hat Secure Boot in sehr sehr vielen (290) Mainboards ab September 2021 durch BIOS Updates ausgehebelt in dem es die Image Execution Policy im Standard auf „Always Execute“ gestellt hat. Auf die Art bringt die Signaturprüfung nix. Aber Windows zeigt happy das der Sichere Start an und das...
Es gab doch auch noch eine Lücke, die entstand, wenn man Secure Boot deaktiviert und wieder aktiviert hat, konnten einem falsche Schlüssel eingespielt werden, nur ein neues aufspielen des Bios konnte die Schlüssel wieder in den Auslieferungszustand versetzen. Die Nachricht dazu finde ich aber leider nicht mehr.
Aber das Secure Boot Problem scheint nicht das einzige zu sein.
MSI H510M-Pro Mainboard also has another problem. The Intel Managment Engine Manufactoring Mode is activated.
Ich habe selbst so ein "betroffenes" Board von MSI, dass MSI Pro Z690-A DDR4 WiFi:
..und die Bios Version x1.43, die der "Professor Lustig" da getestet haben will gibt es bei MSI gar nicht (mehr) und das aus 2 Gründen:
a.) handelt es sich bei dieser Bios Version 100%ig um eine Beta vom 17.05.2022, dafür spricht das "43",
b.) werden Betas von MSI immer durch eine Final abgelöst, in diesem Fall hier die v1.40 vom 24.05.2022, die Betas werden danach dann wieder vom Server genommen.
..und schaut man sich dann einmal die Log zu der final v1.40 vom 24.05.2022 an, dann steht da unter anderen auch folgendes:
Zudem sind nach dem v1.40 noch sage und schreibe 4 weitere Bios Updates gekommen, dass letzte ist vom 11.01.2023, also wenige Tage alt.
..vieleicht sollte der Forscher noch einmal "forschen" und einfach mal die kurz danach erschienene final Biosversion nehmen?
Denn ein "fixed following problem of the previous version setting of Secure Boot" implementiert eigentlich, dass da in der Final etwas gefixt wurde.
Weil das aktuellste auf der Page ist ja 12-08-2022
Beitrag automatisch zusammengeführt:
Davon ab, wenn das erst Greifen muss, es ist afaik eine Vorrausetzung für Windows 11, für mich auch nicht mehr, wenn Schadware schon soweit gekommen ist, bringt mit eine solche Funktion dann auch nix mehr, denn isses längst zu spät
Secure Boot hat nichts mit verschlüsselung zu tun. Es geht einfach darum, dass nur der von MS signierte Bootloader gestartet werden kann. Sicher oder Sinnvoll war Secure Boot noch nie.
Ich habe noch nie davon gehört, dass ein Trojaner in Windows den Bootloader durch eine VM ersetzt hat und das Windows dann komplett in einer VM läuft. Möglich wäre es ja, aber praktisch?
Ich habe nochmal nachgeschaut bei meinem MSI MPG Z790 Edge sind die Defaults mit der neusten produktiven Version ebenfalls auf Durchzug gestellt.
Wer jetzt sagt Secure Boot ist unwichtig, oder es ist alles super, der hat keinen Plan!
Secure Boot dient vor Allem dazu System vor Bootkits und Rootkits und ähnlichem zu schützen, welche am liebsten vor dem Start vom ELAM einnisten, denn dann sind die für AV praktisch unentdeckbar.
Davor schützt auch UEFI Kennwort nicht, wenn sich die Schadsoftware im Kernel einnistet...
Leitfaden zur Erstellung und Verwaltung von Schlüsseln für Windows Sicherer Start
learn.microsoft.com
Nach meinem Verständnis gab es zuviel Stress mit Secure Boot incidents mit Win11 Einführung, wodurch man gesagt hat "ach Hauptsache Windows meckert nicht und wir haben keine Probleme"
Absolutes No-Go ein Sicherheitsfeature so vom Werk aus zu manipulieren. (ACHTUNG SPEKULATION)
@Mr.Mito
Wie nennst du es dann, wenn man ein Security Feature aktiviert und dann die Einstellungen soweit verändert, dass es ad absurdum führt?
Wer Linux betreiben will, wird schon eine Lösung finden und Secure Boot selbstständig ausmachen. Damit sind aber potentiell Tausende wenn nicht Millionen Kunden ungeschützt unterwegs.
Secure Boot dient vor Allem dazu System vor Bootkits und Rootkits und ähnlichem zu schützen, welche am liebsten vor dem Start vom ELAM einnisten, denn dann sind die für AV praktisch unentdeckbar.
Davor schützt auch UEFI Kennwort nicht, wenn sich die Schadsoftware im Kernel einnistet... Anhang anzeigen 843562
Ach joa und wie kommen wie auf's System, genau, abgesehen vom TPM schon immer wenn man sichs ins System reinzieht, wenn es am AV auch eben nicht vorhandenem AV (windows defender) dranvorbei schön tief ins System gekommen ist
Noch Fragen @nebulus1 ?
Wenn du nen Ubuntu (für einige kein richtiges Linux) aufsetzt ist das standard mit (U)EFI , Secure Boot und dem ganzen Zipp und Zapp aktiviert im Bios.
Da kannste garnicht das OS aufsetzen ohne das Passwort zu setzen ;-)
Unter so einem Sicheren Startschlüssel verstehe ich im übrigen das hier
Check out the #1 security key lineup that provides strong two-factor, multi-factor and passwordless authentication!
www.yubico.com
Das ich mich am OS authentifiziere das ich das bin, weil des meine Karre ist, irgendwie andere Baustelle, genauso wie man wohl "Windows Hello?" sein Gesicht wie bei einem Smartphone verwenden könnte.
Da funktioniert seit Jahren, auch auf Windows 10 schon nichts gescheit, lässt sich nicht einrichten.
Meine Fratze mit WebCam wie beim Smartphone, wäre kein Problem, genauso wenig so nen yubikey, is alles vorhanden.
Aber Google und Browser wie Firefox und Chrome unterstützen das schon seit mindestens 5 Jahren etwa, also auch YouTubeaccounts, danach kam denn dieser F2A-Krempel mit der Google-Authenticator app noch dazu....nuja...
Wer Linux betreiben will, wird schon eine Lösung finden und Secure Boot selbstständig ausmachen. Damit sind aber potentiell Tausende wenn nicht Millionen Kunden ungeschützt unterwegs.
Es kommt auf die Distribution an. Debian, Ubuntu, Fedora haben keine Probleme mit Secure Boot. Man kann die ganze Geschichte sogar noch durch Kernelparameter ergänzen, sodass die frühe Startphase abgesichert ist.
Es kommt auf die Distribution an. Debian, Ubuntu, Fedora haben keine Probleme mit Secure Boot. Man kann die ganze Geschichte sogar noch durch Kernelparameter ergänzen, sodass die frühe Startphase abgesichert ist.
Na dann gibt es ja noch weniger Gründe Secure Boot wie ein Scheunentor aufzumachen.
Am Ende bringt das Feature mehr Sicherheit für den Kunden, gerade für den Otto Normal Nutzer, der keinen Plan hat.
@Euphoria
is nur blöd das des bei Windows nicht so läuft wie mit beispielsweise Ubuntu, und nu ?
Ich hab mich bisher nicht weiter drum geschert, bei 10 nicht, sowie bei 11 nicht, "because i know what i'm doing"
Ich habe selbst so ein "betroffenes" Board von MSI, dass MSI Pro Z690-A DDR4 WiFi:
..und die Bios Version x1.43, die der "Professor Lustig" da getestet haben will gibt es bei MSI gar nicht (mehr) und das aus 2 Gründen:
a.) handelt es sich bei dieser Bios Version 100%ig um eine Beta vom 17.05.2022, dafür spricht das "43",
b.) werden Betas von MSI immer durch eine Final abgelöst, in diesem Fall hier die v1.40 vom 24.05.2022, die Betas werden danach dann wieder vom Server genommen.
..und schaut man sich dann einmal die Log zu der final v1.40 vom 24.05.2022 an, dann steht da unter anderen auch folgendes:
Zudem sind nach dem v1.40 noch sage und schreibe 4 weitere Bios Updates gekommen, dass letzte ist vom 11.01.2023, also wenige Tage alt.
..vieleicht sollte der Forscher noch einmal "forschen" und einfach mal die kurz danach erschienene final Biosversion nehmen?
Denn ein "fixed following problem of the previous version setting of Secure Boot" implementiert eigentlich, dass da in der Final etwas gefixt wurde.
Der "Professor Lustig" schreibt, dass ab dieser Version der Standard geändert wurde und dein Changelog wiederlegt das auch nicht, sondern sagt nur, dass der Standard geändert wurde. Es ist seit dem also per default an, aber scheinbar eben mit gesetztem "always execute" für unsignierte Bootloader.
Some example locations:
Settings/Advanced/Windows OS Configuration/Secure Boot
Security/Secure Boot
Then change "Always Execute" to "Deny Execute" on "Removable Media" and
"Fixed Media". Optionally you can also change "Option ROM" to "Deny
Execute", read more about Option ROMs:
Wie nennst du es dann, wenn man ein Security Feature aktiviert und dann die Einstellungen soweit verändert, dass es ad absurdum führt?
Wer Linux betreiben will, wird schon eine Lösung finden und Secure Boot selbstständig ausmachen. Damit sind aber potentiell Tausende wenn nicht Millionen Kunden ungeschützt unterwegs.
Kurzum, beispielsweise nach einem Biosupdate, eine Änderung die ja in Ordnung ist, muss du dann beim Hochfahren, bei Linux zumindest so aus der Praxis...,
Das Passwort wieder eingeben, dürfte dann schon im Bootloader so sein, bei Ubuntu ist das typischerweise "GRUB 2"
Du authorisiert dem Bootloader mit deinem gesetztem Passwort das die Änderung im Bios ok ist, dann fährt es auch hoch, ist das passwort falsch, weil da jemand unbefugtes dran war, fährt es nicht hoch, weil der unbefugte das Passwort natürlich nicht kennt.
Das in Zusammenspiel mit einem verschlüsseltem Datenträger (SSD), bei einem Notebook, is natürlich ziemlich save ;-)
Gruss Dennis
Beitrag automatisch zusammengeführt:
Dasselbe wäre es mit dem MBR (master Boot Record) oder eben GPT (GUID Partition Table), für mein Verständnis, aber dann wäre "GRUB 2" oder auch der Windows-Bootloader auch nicht mehr Original, aber da kommt ja eigentlich TPM in's Spiel
Beitrag automatisch zusammengeführt:
Wo aber immernoch nicht geklärt ist ob der Bug bei TPM 2.0 was wir ja alle maximal haben, es den immernoch gibt.
Irgendwann einmal, schon sehr lange her hab ich mal irgendwo nen Link dazu gepostet, ich glaub das war eventuell "heise" oder "golem" da wurde vor X Jahren jedenfalls von einem Bug bei TPM 2.0 berichtet wovon man nie wieder was gelesen oder gehört hat, das des mal gefixt worden ist.
[English]Eine neue entdeckte Schwachstelle ermöglicht es, ECDSA-Signaturschlüssel per Timing-Angriff aus dem vermeintlich gesicherten Speicherbereich von TPM-Chips (Intel fTPM 2.0…
Exakt das ist eben nicht Secure Boot, sondern TPM, nur mal kurz drüber nachgedacht warum viele gegen TPM waren als Systemvorraussetzung, keine Signatur keine Execution von der CPU davon...
Am Ende des Tages muss beides gescheit funktionieren, wie beschrieben.
Deswegen war es früher auch egal, wenn man Secure Boot deaktiviert und CSM nutzte, TPM hatten halt die wenigsten und Secure Boot alleine bringt halt nichts, was sich nun mit neuerer Hardware geändert hat, (f)TPM was in den aktuelleren, in all denen integriert ist.
Ansonsten hätte ich gerne eine gescheite Quelle dazu
Gruss Dennis
Beitrag automatisch zusammengeführt:
Bitlocker ist Windows eigenes TrueCrypt im übrigen, ganz andere Baustelle....
Beitrag automatisch zusammengeführt:
Zitat
Der Einsatz von Bitlocker setzt voraus, dass ein Windows-7-Ultimate- oder das Enterprise-Betriebssystem zum Einsatz kommt. Microsoft bietet die Laufwerksverschlüsselung leider nur auf diesen Versionen seines Client-Betriebssystems und auf dem Windows Server 2008 (und auch dem Windows Server 2008 R2) an.
Heute endet das ESU-Programm von Windows 7, doch Microsoft hält noch eine Überraschung bereit. Das alte Betriebssystem erhält Secure Boot.
www.computerbase.de
Secure Boot hat Windows 7 vor kurzem erst bekommen...
Beitrag automatisch zusammengeführt:
Nur weil das eine auch eine Passworterstellung verlangt und das auch abfragt ist es nicht dasselbe oder eine "alte" Version davon...
TrueCrypt lief auch auf nem Athlon XP, da gab es kein Secureboot, kein (f)TPM und auch noch kein Bitlocker (truecrypt und bitlocker sind aber an sich dasselbe als solches, datenträgerverschlüsselung mit Passworterstellung und Abfrage für den Zugriff, mitunter Booten ja, logisch, ohne Entschlüsselung kein Booten)
Beitrag automatisch zusammengeführt:
Man das waren noch Zeiten, da war ich noch jung als Truecrypt der heisse gewesen ist (ich bin Baujahr 1988 ;-) )
Du solltest mal verstehen, mit logischen Denken, wie deine Kiste funktioniert....
Beitrag automatisch zusammengeführt:
Vor dem Bootloader ist keine Verschlüsselung, man könnte den verschlüsselten Bootloader (partition) sonst nicht Booten, Datenträgerverschlüsselung kommt nach dem Bootloader bzw. mit dem Bootloader, ursprünglicherweise.
TPM ist nun aber mittlerweil Bestandteil davon, das kommt schon viel eher zum Einsatz und Verschlüsselung geht auch:
Die SSD-FAQ: Aktuelle SSD-Technologien im Überblick Zitat: Eine Verschlüsselung muss nicht auf die Leistung auswirken Wie bei allen Produktkategorien gibt es natürlich auch bei den SSDs ausgemachte Spezialisten für verschiedene Bereiche. Gerade für den Unternehmenseinsatz kann eine in der...
www.hardwareluxx.de
nennt sich mit meiner Kingston A-2000 dann "TCG-Opal 2.0" und ist soweit ich das sehe Bitlocker-kompatibel
Wer redet denn von Verschlüsselung? Darum geht es gar nicht.
Es geht darum, dass Secureboot nur signierte Software startet.
What is UEFI Secure Boot?
UEFI Secure boot is a verification mechanism for ensuring that code launched by firmware is trusted.
Proper, secure use of UEFI Secure Boot requires that each binary loaded at boot is validated against known keys, located in firmware, that denote trusted vendors and sources for the binaries, or trusted specific binaries that can be identified via cryptographic hashing.
Most x86 hardware comes from the factory pre-loaded with Microsoft keys. This means we can generally rely on the firmware on these systems to trust binaries that are signed by Microsoft, and the Linux community heavily relies on this assumption for Secure Boot to work. This is the same process used by Red Hat and SUSE, for instance.
Many ARM and other architectures also support UEFI Secure Boot, but may not be pre-loading keys in firmware. On these architectures, it may be necessary to re-sign boot images with a certificate that is loaded in firmware by the owner of the hardware.
Ich kann im übrigen nix dazu, wenn du sinnvollen Vergleichen nicht folgen kannst...logisches Denken, weil man die Bude versteht
Und was passiert wenn "GRUB 2" geupdatet worden ist ? quasi ein Update mit Adminrechten..., joa ist ja geil das Secure Boot wa....
Signaturen "fälschen" ist im übrigen nicht so schwer, deshalb schaltet man in AV's am besten auch aus, das wenn Signaturen vorhanden sind in Dateien, das diese dann nicht geprüft werden, weil die nunmal besser gepürft werden mit der Heuristik (wenn se denn gescheit ist und nicht false positive raushauen bis zum Abwinken)
Beitrag automatisch zusammengeführt:
Du solltest mal aufhören mit deinem Tunnelblick wie ein 14-Jähriger und mal das grosse ganze sehen...
Beitrag automatisch zusammengeführt:
Du kannst im Bios bei SecureBoot auch die Keys alle löschen, und dann ?
Da kommt denn das Passwort zum tragen...., auch da dann, damit die wieder eingetragen werden, zum Beispiel eben nach einem Biosupdate, folglich nem CMOS-Clear
Beitrag automatisch zusammengeführt:
Desweiteren, Zitat:
Ein zweiter Schlüssel, Attestation Identity Key (AIK) genannt, schützt das Gerät vor nicht autorisierter Firmware- und Softwareänderung, indem er kritische Abschnitte von diesen hasht, bevor er sie ausführt. Wenn das System versucht, eine Verbindung zum Netzwerk herzustellen, werden die Hashes an einen Server gesendet, der überprüft, ob sie mit den erwarteten Werten übereinstimmen. Bei Änderungen an der gehashten Komponente schlagen die Übereinstimmung fehl und das System erhält keinen Zugang zum Netzwerk.
Ein Trusted Platform Module (TPM) ist ein spezialisierter Chip, der Hardware mit integrierten kryptografischen Schlüsseln sichert.
www.computerweekly.com
Alter Kakao...
Was ist denn bitte Firmware... BIOS, genauso auch das was eine Grafikkarte hat, SSD's, HDD's.....
Klingelts ?
Gruss Dennis
Beitrag automatisch zusammengeführt:
Oder auch das Mikrocodeupdate (für die CPU, bei veralteter Version im Bios davon) über Bootloader, was man bei Windows seitens MS mittlerweile genauso macht, seit Win10 spätestens denk sogar Win8 bzw 8.1 sogar schon, wie bei Linux, beispielsweise mit GRUB2 bei der Ubuntu-Distribution....
Der Sicherheitsexperte scheint ja sein Geld wirklich wert zu sein, wenn er ein nötiges - und bei Powerusern hinlänglich bekanntem - _Feature_ übertrieben aufgebauscht als Sicherheitslücke anprangern muss, um Aufmerksamkeit zu erzeugen.
Wer Motherboards selber einbaut sollte auch ins Bios schauen und macht das auch für gewöhnlich. Da gibts noch ganz andere Optionen die viel unsicherer sind. Ob das default so eingestellt sein sollte, kann man drüber streiten, aber Biossettings zu überprüfen ist Pflicht des Users. Viel wichtiger ist, dass MSI secureboot umgehen kann um die unsäglichen Gängelungen seitens MIcrosoft abfedern zu können, wenn schon die Presse viel zu oft M$ in den Allerwertesten kriecht.. Ansonsten würde so manch anderes Betriebssystem gar nicht booten können. Und Microsoft ist wie bei Browsern kein Move zu schäbig, um Alternativen rauszudrängen oder ganz zu unterbinden... natürlich alles NUR im Sinne des Users und seiner Sicherheit.
Kurzum, beispielsweise nach einem Biosupdate, eine Änderung die ja in Ordnung ist, muss du dann beim Hochfahren, bei Linux zumindest so aus der Praxis...,
Das Passwort wieder eingeben, dürfte dann schon im Bootloader so sein, bei Ubuntu ist das typischerweise "GRUB 2"
Du authorisiert dem Bootloader mit deinem gesetztem Passwort das die Änderung im Bios ok ist, dann fährt es auch hoch, ist das passwort falsch, weil da jemand unbefugtes dran war, fährt es nicht hoch, weil der unbefugte das Passwort natürlich nicht kennt.
deshalb schaltet man in AV's am besten auch aus, das wenn Signaturen vorhanden sind in Dateien, das diese dann nicht geprüft werden, weil die nunmal besser gepürft werden mit der Heuristik (wenn se denn gescheit ist und nicht false positive raushauen bis zum Abwinken)
Da kommt denn das Passwort zum tragen...., auch da dann, damit die wieder eingetragen werden, zum Beispiel eben nach einem Biosupdate, folglich nem CMOS-Clear
Puh, selbst wenn in den Beiträgen von Dennis was korrektes drin stehen würde, habe ich irgendwie gar keine Lust mich durch die zusammengefassten Beiträge zu wühlen.
(ich bin Baujahr 1988 ;-) )
