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.
NewsWindows 10: Neuer Intel-Microcode gegen Spectre V3a, V4 & L1TF
Eine gegenteilige Meinung/Ansicht zu haben, bedeutet nicht zwingend automatisch einen Aluhut aufhaben zu müssen. Sehen wir es doch einfach als Einwurf - die Konsequenzen daraus muss jeder für sich selbst in Kauf nehmen, sind doch mündig, oder nicht?
Deswegen ja das Beispiel Javascript. Dort lädst Du nämlich Fremdcode auf Deinem Rechner und lässt das ausführen. Das ist ja mit einer Cloudumgebung zumindest vergleichbar.
Klar haben die Browserhersteller das Problem entschärft. Allen voran damit, dass man keine genauen Timer mehr zur Verfügung stellt (wichtig bei solchen Attacken ist das Timing; wurde auch schon mehrmals hier durchgekaut; du brauchst es also nicht wiederholen), aber das Problem ist damit nicht aus der Welt. Und man muss eben damit rechnen, dass irgend ein findiger Spezi trotzdem einen Weg findet.
Ich glaube selbst von den CPU-Herstellern würde sich keiner so weit aus dem Fenster lehnen und sagen, dass jetzt alles sicher ist.
Das zeigt ja allein die Tatsache das immer wieder neue Varianten rund um Meltdown/Spectre bekannt werden.
andr_gin schrieb:
Das ist ein sehr simpler Exploit, lässt sich jedoch selbst mit einem kompletten CPU Redesign nicht fixen ohne auf das Performanceniveau von vor 2000 zurück zu fallen.
Auch hier missverstehst Du mich wieder komplett (wobei mir das Warum unklar ist bei dem Umfang meiner Erläuterung). Ich sag ja nicht, dass die Lücken automatisch für jeden ein Problem sind.
Eine "Wir werden alle sterben"-Rhetorik ist sicherlich unangebracht. Aber genauso unangebracht ist eine "Ihr könnt bedenkenlos alle Mitigations abschalten"-Rhetorik.
Übrigens: Mit einem CPU-Redesign ließen sich die Probleme schon fixen. Auch ohne Performance zu verlieren. Nur ist das halt aufwändig und jeglicher Hinsicht. Zum Beispiel auch weil auch große Teile der Software angepasst werden müssten. Bisher wurden CPUs hauptsächlich so designed, dass sie vorhandene Software schnell(er) ausführen. CPUs die andere Wege versucht haben, haben sich (leider) bisher nicht durchsetzen können. Das hat ja letztlich zu einer "Überoptimierung" geführt. Eben das man auf Tricks zurückgreifen musste die mehr Hacks waren, aber anders ließ sich halt die Performance nicht steigern. Und nun fällt einen das auf die Füße.
Ergänzung ()
Stunrise schrieb:
Der Vollständigkeit halber habe ich noch den MCSE für Messaging sowie MCSA für Server 2012 und noch ein paar ältere Sachen
Das Problem sind ja eigentlich auch nicht die Inhalte solcher Sachen, sondern wie man die präsentiert.
Ich komm ja auch nicht auf die Idee mich als Profi für Internettechnologien zu präsentieren, weil ich vielleicht irgendwie ein Internetführerschein aus der Volkshochschule vorweisen kann. :-)
@inge70 ist das nicht etwas unsicher, dass ich global einfach die policy ändere um scripte auszuführen? wie mach ich das wieder rückgängig. kann man das nich nur einmal zulassen oder nur für das eine script.
genau davon rede ich ja. wer bitte soll es denn auf einen otto wie mich abgesehen haben.
deshalb beunruhigt MICH dieses thema nicht und ich behalte lieber meine performance meiner eh schon an der kotzgrenze rennenden cpu.
nicht mehr oder weniger habe ich geschrieben.
Dich erwischt es aus reinem Zufall, wie viele andere auch bereits erwischt worden sind und noch erwischt werden.
Wenn du auf eine gefakete Seite gerätst, oder unbekannte E-Mail-Anhänge oder Links öffnest, kann es dich natürlich explizit treffen.
Aber jeder, wie er es für richtig hält. Mehr als warnen und hinweisen kann man nicht.
@Andybmf, ich denke @Miuwa meinte dass es Deine Annahme war, jemand müsse es auf Dich abgesehen haben. Er wollte (wie andere) meiner Meinung nach herausstellen, dass eben das nicht der Fall sein muss. So liest sich jedenfalls der Rest seines Beitrags.
Hallo zusammen,
da ich mich normalerweise wegen der ganzen Meltdown/Spectre Thematik nicht habe verrrückt machen lassen, aber trotzdem immer alle Windows-Patches installiere, wollte ich Euch nochmal fragen, ob bei alleiniger Windows-Nutzung die Patches an sich ausreichen oder man noch zwingend das BIOS des Mainboards aktualisieren muss/sollte? Hintergrund ist folgender:
Da ich mir im März eine neue Plattform (siehe Signatur) zusammengestellt hatte, begann ich wieder regelmässig das BIOS zu aktualisieren. Bei meinem ASRock Board war deshalb bereits im BIOS P1.80 der allererste Meltdown/Spectre Fix (Intel Mikrocode 84) enthalten. Seit BIOS Version P3.10 (Juli Mikrocode + ME-Update) bekam ich dann jedoch nach den Updates Bootprobleme (mein Thread im ASRock Forum schildert besonders auf Seite 3 den letzten Stand: http://forum.asrock.com/forum_posts.asp?TID=9198&title=z370-pro4-bootprobleme-nach-bios-update-310), so dass sich erst nach mehreren CMOS Resets das System wieder gefangen hatte. Mit BIOS P3.20 (L1TF und Foreshadow, wenn ich mich recht erinnere) ging dann gar nichts mehr und es hatte sich dann die Graka als defekt rausgestellt. Leider weiss ich bis heute nicht, ob die An-Aus-An-Vorgänge nach den BIOS-Updates, wo die Geräte wieder ins UEFI eingetragen werden, Schuld an der Misere sind oder ob die Graka schon so am Sterben war. Da der Rechner nun mit dem BIOS P3.20 und der ausgetauschten Graka wieder super läuft, habe ich etwas Angst, dass BIOS wegen weiterer Mikrocode-Implmentierungen erneut zu updaten. Nun schwanke ich zwischen "Dont change running system" und "change system to a secure one" und weiss nicht weiter. Was würdet ihr machen?
@Andybmf: wie Sagrath und Micha45 richtig erkannt haben hast du mich da missverstanden.
Versteh mich nicht falsch, ich habe keine Ahnung, wie wahrscheinlich es ist, dass die Lücke ausgenutzt wird oder was du für Daten im Speicher deines Computers hast oder was sich realistisch auslesen lässt (schon mal deine Kreditkartennummer im Browser eingegeben? Oder hast du ein Email Konto ohne zweifaktor Authentifizierung - sprich nur per Passwort gesichert? Das wären z.B. interessante Daten).
Es geht mir nur grundsätzlich darum, dass es eine Fehlannahme ist, jemand müsste dich gezielt und manuell angreifen damit du zum Opfer wirst.
Deswegen ja das Beispiel Javascript. Dort lädst Du nämlich Fremdcode auf Deinem Rechner und lässt das ausführen. Das ist ja mit einer Cloudumgebung zumindest vergleichbar.
Klar haben die Browserhersteller das Problem entschärft. Allen voran damit, dass man keine genauen Timer mehr zur Verfügung stellt (wichtig bei solchen Attacken ist das Timing; wurde auch schon mehrmals hier durchgekaut; du brauchst es also nicht wiederholen), aber das Problem ist damit nicht aus der Welt. Und man muss eben damit rechnen, dass irgend ein findiger Spezi trotzdem einen Weg findet.
Der entscheidende Punkt ist:
Keine dieser Microcodeupdates fixed Spectre V1. Das lässt sich über Microcode nicht fixen und ist auch am einfachsten auszunutzen. Die Erkenntnis nach Spectre V1 ist:
Wenn man eine Skriptsprache zur Verfügung stellt, in der nicht sicherer Code ausgeführt wird, dann darf diese keine genauen Timingfunktionen bieten, sonst ist das System nicht sicher. Die Ausnahme sind lediglich Virenscanner Engines, da diese so weit isolieren, dass der nicht sichere Code zwar Lesezugriffe tätigen kann, jedoch keine Chance hat diese irgendwie zu verwerten.
Ich glaube selbst von den CPU-Herstellern würde sich keiner so weit aus dem Fenster lehnen und sagen, dass jetzt alles sicher ist.
Das zeigt ja allein die Tatsache das immer wieder neue Varianten rund um Meltdown/Spectre bekannt werden.
Natürlich können da noch weitere Lücken oder Backdoors versteckt sein. Gegen nicht gefundene Lücken nützt neuer Microcode jedoch kaum etwas.
Auch hier missverstehst Du mich wieder komplett (wobei mir das Warum unklar ist bei dem Umfang meiner Erläuterung). Ich sag ja nicht, dass die Lücken automatisch für jeden ein Problem sind.
Eine "Wir werden alle sterben"-Rhetorik ist sicherlich unangebracht. Aber genauso unangebracht ist eine "Ihr könnt bedenkenlos alle Mitigations abschalten"-Rhetorik.
Solange nicht einmal im Ansatz eine Gefährdung gegeben sein kann, da es sich hier nur um Rechteausweitungen handelt über Grenzen, die auf einem Desktopsystem sowieso irrelevant sind kann man das Ganze bedenkenlos abschalten. Umgekehrt sehe ich hier mehr Risiko durch die Microcode Updates, die dann die Stabilität des Systems gefährden. Es gibt ja mehr als genug Systeme, die nach den Updates gar nicht mehr gelaufen sind.
Übrigens: Mit einem CPU-Redesign ließen sich die Probleme schon fixen. Auch ohne Performance zu verlieren. Nur ist das halt aufwändig und jeglicher Hinsicht. Zum Beispiel auch weil auch große Teile der Software angepasst werden müssten. Bisher wurden CPUs hauptsächlich so designed, dass sie vorhandene Software schnell(er) ausführen. CPUs die andere Wege versucht haben, haben sich (leider) bisher nicht durchsetzen können. Das hat ja letztlich zu einer "Überoptimierung" geführt. Eben das man auf Tricks zurückgreifen musste die mehr Hacks waren, aber anders ließ sich halt die Performance nicht steigern. Und nun fällt einen das auf die Füße.
Spectre V1 lässt sich nur auf Hardwareebene fixen indem die spekulative Ausführung komplett deaktiviert wird. Dann muss bei jedem if und jedem erneuten Schleifendurchlauf die Pipeline komplett neue gefüllt werden, selbst bei Schleifen, die ein paar Millionen Mal durchlaufen und lediglich eine Rechenoperation enthalten. Da sind wird zurück in 386er Zeiten.
Das Problem sind ja eigentlich auch nicht die Inhalte solcher Sachen, sondern wie man die präsentiert.
Ich komm ja auch nicht auf die Idee mich als Profi für Internettechnologien zu präsentieren, weil ich vielleicht irgendwie ein Internetführerschein aus der Volkshochschule vorweisen kann. :-)
Das Problem ist, dass die Funktionsweise einer Lücke gar nicht mehr diskuttiert wird, damit sich jeder selbst ein Bild davon machen kann. Stattdessen kommen nur mehr kumulierte Updates und es wird jedem eingeredet er ist unsicher, wenn er diese nicht sofort automatisch installieren lässt.
Mensch, bin ich froh! Weder mein 286er noch mein 386er sind davon betroffen! ^^
Da sagt doch bitte einer nochmal, dass Altsysteme immer unsicherer sind als neue..
Ein Hoch auf die ganzen C64, Amiga, DOS/Win 3.11-Systeme, die noch laufen!
@joshy337 Ein Kollege von mir ist total retro unterwegs und nutzt einen Amiga 4000 mit dem letzten Amiga OS. Da ist die Retro-Szene massiv aktiv, baut Hardware der 90er nach, macht sie kompatibel mit anderen und bringt neue Versionen der alten Betriebssysteme raus. Der hat die Probleme auch nicht.
Es geht ja dabei auch um Lücken, die man bisher als nicht als überaus problematisch eingestuft hat. Aber man bietet halt trotzdem vorsichtshalber eine Mitigation an. Nu kann man sagen, dass man die nicht aktiviert, weil die Performance kostet und eh nix bringt.
Nur kann morgen eben schon jemand kommen und nen besseren "Exploit" entwickelt haben. Und dann wird diese Lücke plötzlich doch problematischer. Und die Mitigation umso wichtiger.
Jetzt klar?
andr_gin schrieb:
Spectre V1 lässt sich nur auf Hardwareebene fixen indem die spekulative Ausführung komplett deaktiviert wird. Dann muss bei jedem if und jedem erneuten Schleifendurchlauf die Pipeline komplett neue gefüllt werden, selbst bei Schleifen, die ein paar Millionen Mal durchlaufen und lediglich eine Rechenoperation enthalten. Da sind wird zurück in 386er Zeiten.
Eben genau deshalb sprach ich von neuem CPU-Design. Du kannst ja jetzt schlecht dagegen argumentieren, in dem Du Schwächen des jetzigen CPU-Designs heranführst.
andr_gin schrieb:
Das Problem ist, dass die Funktionsweise einer Lücke gar nicht mehr diskuttiert wird, damit sich jeder selbst ein Bild davon machen kann.
Das klappt aber nur bei einigermaßen versierten Nutzern. Beim Nutzertyp a-la "Hilfe, mein Bildschirmhintergrund ist anders!!11!" da brauchste nicht ankommen mit Erklärungen zu branch-prediction und speculative-execution usw.
Das heißt nicht, dass man darüber nicht reden kann. Nur hilft das dem "DAU" eben nicht weiter. Deshalb sagt man dem: "Verstell das liber nix bevor Du was kaputt machst"
andr_gin schrieb:
Es gibt ja mehr als genug Systeme, die nach den Updates gar nicht mehr gelaufen sind.
