Spectre und Meltdown

Skynet kann jetzt dank Spectre und Meltdown richtig durchstarten.

Nachdem ich nun auch das Meltdown –Beispiel (nur für Linux) getestet habe, das merkwürdigerweise heute wohl nicht mehr auf github erreichbar ist, muss ich feststellen, dass dieses so nicht funktioniert. Vielleicht haben die Autoren es auch deshalb entfernt oder vielleicht habe ich die asm Routinen nicht richtig nach 32bit umgeschrieben – ich habe leider keinen 64bit Linux Testcomputer. Es gibt aktuell noch ein anderes github Projekt zum dem Thema - aber auch hier kommt der Autor selbst zu dem Ergebnis, das es so nicht funktioniert.
Sowohl das Original als auch die "Weiterentwicklung" lesen grundsätzlich nur Nullen aus und können auch nicht auf den Programm- zugewiesenen Speicher zugreifen. Es scheitert wohl an dem, was die Autoren auch schon als Problem identifiziert haben: „Need for Exception Suppression“.
Im Moment stellt sich mir die Frage: Was bleibt nun übrig von der ach so großen Sicherheitslücke ?

hustbaer

Das Auslesen von Speicher anderer Prozesse funktioniert mit Meltdown nur auf 64 Bit Kernels. Das Auslesen des Kernel Speichers sollte überall funktionieren.

Zweifler schrieb:

Was bleibt nun übrig von der ach so großen Sicherheitslücke ?

Weil du und 1-2 andere "Profis" es nicht hinbekommen haben funktioniert es nicht, hm? Na dann ist ja alles in Butter und Microsoft, Apple, Intel etc. waren alle bloss zu doof es auszuprobieren und haben Patches wegen nichts entwickelt.

Mechanics

computertrolls schrieb:

Der CERT vom BSI schreibt, dass die Sicherheitslücken CVE-2017-5715 (Spectre) und CVE-2017-5753 (Spectre) vermutlich von einem Angreifer im benachbarten Netzwerk ausgenutzt werden kann.
Damit wäre ein gegen diese Schwachstellen anfälliger Router direkt betroffen und für den gilt, dass das benachbarte Netzwerk auch das Internet selbst sein kann, schließlich hat er eine eigene öffentliche IP.

Irgendwie schaut deren Beschreibung nicht wirklich sinnvoll aus. Und oben steht in der Zusammenfassung ja auch, remote ausführbar - nein.

hustbaer

computertrolls schrieb:

Der CERT vom BSI schreibt, dass die Sicherheitslücken CVE-2017-5715 (Spectre) und CVE-2017-5753 (Spectre) vermutlich von einem Angreifer im benachbarten Netzwerk ausgenutzt werden kann.

Ja, tun sie.
In der Beschreibung zu https://nvd.nist.gov/vuln/detail/CVE-2017-5715 steht allerdings
Attack Vector (AV): Local

Und in der Beschreibung von https://nvd.nist.gov/vuln/detail/CVE-2017-5753 steht

Systems with microprocessors utilizing speculative execution and branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis.

Ich würde also sagen die CERT Jungs haben Mist geschrieben.

Ist meine Vermutung richtig, dass es sicherer ist zum Surfen jetzt Chrome anstatt Firefox zu verwenden, weil Chrome im Gegensatz zu Firefox die einzelnen geöffneten Webseiten in getrennte Prozesse auslagert, was bei Firefox noch alles ein Prozess ist?

Denn immerhin kann mithilfe von Spectre unter Verwendung von JavaScript der Speicher des JavaScript Interpreters ausgelesen werden.
D.h. die Sicherheit wird also dadurch erhöht, in dem jede Webseite und der dafür zuständige JS Interpreter in einem eigenständigen Prozess läuft.
Damit wären die Webseiten voneinander ausreichend getrennt.

Ist das so richtig?

hustbaer

Bei der aktuellen Chrome Version musst du extra noch ein Setting aktivieren um gegen den JavaScript Angriff geschützt zu sein: \1://flags#enable-site-per-process
In der aktuellen Chrome Version (63) ist Default noch "disabled" - wird angeblich mit Version 64 auf "default=enabled" umgestellt.

Firefox löst das Problem anders, nämlich indem die Auflösung der High-Resolution Clock ( Performance.now ) künstlich beschnitten wird und das SharedArrayBuffer Feature (mit dem man sich in einem Worker-Thread eine eigene High-Resolution Clock nachbauen könnte) deaktiviert.
Diese Änderungen sind dafür bereits im aktuellen Firefox Release (Update 57.0.4) enthalten.

Was davon jetzt die sicherere Variante ist weiss ich nicht. *

Auf jeden Fall sollten die Browser-Hersteller mMn. zusehen dass so wenig wie möglich "problematische" Daten im Speicher von Prozessen stehen die auch Java-Script Code ausführen. Bzw. allgemein in jedem Prozess. Also z.B. auch gespeicherte Passwörter nur verschlüsselt vorhalten, und zwar so verschlüsselt dass der zum Entschlüsseln nötige Key nur im Kernel-Mode bekannt ist. Und nur kurzfristig entschlüsseln was gerade gebraucht wird, und danach sofort wieder überschreiben. (Oder gleich gar nicht im Speicher halten und nur jedes mal bei Bedarf aus dem File laden. Wobei das eingegebene Passwort muss im Speicher bleiben, sonst müsste man jedes mal das Master-Passwort neu eingeben. D.h. zumindest das eingegebene Passwort müsste irgendwie so verschlüsselt werden dass nur der Kernel es entschlüsseln kann.)

Ich kann nur hoffen dass zumindest das Firefox und das Chrome Team bereits daran arbeiten.

*: Wenn man annimmt dass die Änderungen die Firefox gemacht hat ausreichend sind, dann ist mir Firefox lieber, da diese Änderungen dann das Auslesen komplett verhindern anstatt nur zu versuchen so viel wie möglich Daten aus dem verwundbaren Prozess raus zu bekommen. Ideal wäre vermutlich beides. Wobei man SharedArrayBuffer ein Feature ist das man vermutlich sehr vermissen würde wenn es für ewig deaktiviert bleiben muss. Womit wir dann wieder bei der Chrome Variante landen würden.
Andrerseits könnte man vielleicht den JIT so anpassen dass er erkennt wenn ein JavaScript Worker-Thread immer wieder die selbe Speicherstelle in einem shared buffer überschreibt. Solche Threads massiv zu bremsen könnte vielleicht auch reichen.

hustbaer schrieb:

Firefox löst das Problem anders, nämlich indem die Auflösung der High-Resolution Clock ( Performance.now ) künstlich beschnitten wird und das SharedArrayBuffer Feature (mit dem man sich in einem Worker-Thread eine eigene High-Resolution Clock nachbauen könnte) deaktiviert.
Diese Änderungen sind dafür bereits im aktuellen Firefox Release (Update 57.0.4) enthalten.

Was davon jetzt die sicherere Variante ist weiss ich nicht. *

Der Firefox Fix ist mir bekannt. Das Problem bleibt bei dem aber, dass alle Passwörter aller Webseiten, die der Prozess ins RAM geladen hat, theoretisch im Adressraum des Prozess verfügbar sind.

Die Herabsetzung der Genauigkeit der Uhr löst das Problem also unter Umständen nicht gänzlich, sondern macht nur den Spectre Angriff schwieriger

Bei Chrome wäre das zur Webseite passende Passwort, in seinem jeweils eigenen Prozess und somit eigenem Adressraum.
Eine Webseite mit einer Javascript Malware, könnte somit nicht auf das Passwort von einer anderen Webseite zugreifen, weil die beide in unterschiedlichen Prozessen in ihrem jeweils eigenen Adressraum laufen.

Ein PW Diebstahl wäre hier also unmöglich, bei FF wäre er theoretisch noch möglich, falls der Angreifer mit der ungenauen Uhr trotzdem noch einen Weg findet den Spectre Angriff zu nutzen.
So wäre zumindest meine Überlegung zu dem Thema.

Der FF Fix wirkt somit auch eher wie ein schneller Hack, da er schnell umsetzbar ist.

Denn ich vermute mal, dass der Aufwand FF beizubringen für verschiedene Webseiten einen eigenen Prozess zu nutzen viel höher ist.

hustbaer

computertrolls schrieb:

Die Herabsetzung der Genauigkeit der Uhr löst das Problem also unter Umständen nicht gänzlich, sondern macht nur den Spectre Angriff schwieriger

Ja, klar. Dazu muss es aber erstmal jemand schaffen den Angriff trotz ungenauer Uhr trotzdem durchzufüren. Ich vermute dass es auch mit recht schlechter Auflösung funktionieren wird, nur mit extrem gesteigertem Aufwand. Also wenn in 90% der Fälle kein "Tick" zwischen Beginn und Ende des RAM-Zugriffs vergeht, dann musst du schon nen Haufen Versuche mitteln um auf eine akzeptable Fehlerrate zu kommen. Jemand mit Ahnung von Mathematik/Statistik kann dazu sicherlich genaueres sagen. Irgendwann ist auf jeden Fall der Punkt erreicht wo es nicht mehr interessant ist für Hacker, da sie kaum Ergebnisse bekommen würden - also wenn so ein Angriff z.B. etliche zig Stunden dauern würde.

computertrolls schrieb:

Bei Chrome wäre das zur Webseite passende Passwort, in seinem jeweils eigenen Prozess und somit eigenem Adressraum.
Eine Webseite mit einer Javascript Malware, könnte somit nicht auf das Passwort von einer anderen Webseite zugreifen, weil die beide in unterschiedlichen Prozessen in ihrem jeweils eigenen Adressraum laufen.

Ja, WENN die Chrome Programmierer sonst keinen "Mist" gebaut haben. Wer sagt denn dass das so ist? Wenn ich darauf vertraue dass JavaScript eh nicht aus seiner Sandbox ausbrechen kann, wieso sollte ich dann extra aufpassen nix "schützenswertes" im RAM meines Prozesses zu haben? (Natürlich gibt es immer wieder andere Exploits, und damit immer gute Gründe sensible Daten möglichst aus dem Speicher des Browsers zu verbannen. Aber so krass wie bei Spectre war es halt sonst nie.)

Wird der Bug in den NextGen-CPUs von AMD und Intel gefixt sein?

gfdgdgf schrieb:

Wird der Bug in den NextGen-CPUs von AMD und Intel gefixt sein?

Im Worst Case Fall dauert es 5 Jahre.
Also kannst du im Jahr 2023 wieder unbesorgt eine CPU kaufen:

A fundamental flaw in the architecture will cost you five years and hundreds of millions of dollars.

https://danluu.com/hardware-unforgiving/

Im übrigen würde ich stark annehmen, das Intel das Problem schneller fixen wird können als AMD. Denn die haben wesentlich mehr Manpower, Fabriken und Labore.
Gut möglich, dass die parallel in Teams einen Fix entwickeln um wieder schnell eine fehlerfreie CPU auf dem Markt anbieten zu können.

Letzteres könnten sie jetzt schon in etwa 10 Monaten erreichen.
Sie müssten nur die Pläne des alten Atom mit der In Order Execution herauskramen, davon einen Die-Shrink machen. Was wegen der Art und Weise, wie Lithografie funktioniert kein großes Problem sein dürfte und dann noch den Takt erhöhen, der durch den Die-Shrink und die niedrigeren Spannungen dann möglich sein dürfte.
Das einzige Problem dabei wäre, dass die meisten Extensions >= SSE4 dann fehlen dürften. Die gab es erst mit Silvermont und das ist ein Out-Of-Order Execution CPU. DDR4 Anbindung gäbe es auch nicht. Ebenso wäre die iGPU nicht auf der Höhe der Zeit (<= DirectX 9 Support). Aber durch den Die-Shrink wäre zumindest ein höherer Takt möglich, womit die CPU auch ansonsten schneller als die alten Atom sein dürften.
Intel hätte hier sogar noch mit Briarwood (Releasedatum Quartal 2 2013) eine Server CPU der Bonnel Architektur im Peto.

AMD hat dagegen nichts auf die Schnelle anzubieten, die müssen ihre Out-Of-Order Execution Einheit reparieren, genau wie Intel auch bei deren größeren CPUs und das wird dauern. Vor allem hat AMD keine große Manpower und nicht so viele Teams wie Intel. Da sind sie also deutlich im Nachteil.
Das AMD weniger fixen muss, ist da nur ein kleiner Vorteil.

hustbaer

Die CPU hat keine "Fehler" in dem Sinn, ich würde das eher als Problem bezeichnen. Die Unterscheidung finde ich deswegen wichtig weil man "Fehler" typischerweise exakt festnageln und beheben kann. Hier ist das anders, bei der Menge an Optimierungen die alle das Timing von bestimmten Vorgängen ändern können, und alle nötig sind damit die CPUs ordentlich schnell sind, ist es kaum möglich irgendwann zu sagen "das ist jetzt 100% wasserdicht".

Im Worst Case wird es also ewig dauern.

hustbaer

computertrolls schrieb:

Sie müssten nur die Pläne des alten Atom mit der In Order Execution herauskramen, davon einen Die-Shrink machen. Was wegen der Art und Weise, wie Lithografie funktioniert kein großes Problem sein dürfte und dann noch den Takt erhöhen, der durch den Die-Shrink und die niedrigeren Spannungen dann möglich sein dürfte.
Das einzige Problem dabei wäre, dass die meisten Extensions >= SSE4 dann fehlen dürften. Die gab es erst mit Silvermont und das ist ein Out-Of-Order Execution CPU. DDR4 Anbindung gäbe es auch nicht. Ebenso wäre die iGPU nicht auf der Höhe der Zeit (<= DirectX 9 Support).

Die von dir genannten Probleme sind IMO keine, das Zeug liesse sich ganz schnell integrieren wenn man es braucht.

Das echte Problem wäre dass du dann wieder ne CPU hast die lahm ist. Denn die Atome von damals waren auch verglichen mit CPUs mit identischem Takt lahm.

Und ich bin mir auch fast sicher dass man ähnliche Angriffe auch für Atom konstruieren kann. Vielleicht nur welche die lange nicht praktikabel sind, aber Timing-Unterschiede über die man an bestimmte "verbotene" Informationen kommen kann gibt es auch bei Atom CPUs.

hustbaer schrieb:

Die von dir genannten Probleme sind IMO keine, das Zeug liesse sich ganz schnell integrieren wenn man es braucht.

Ich weiß nicht wie lange es dauert, eine Extension einzubauen, aber bei nur < 10 Monaten hätte ich meine Zweifel dass das klappt.
Die fertigen von Skylake und Co sind, so schätze ich mal, sicher alle für deren out of Order Architektur gemacht und daher nicht 1:1 auf den alten Atom kopierbar.

Das echte Problem wäre dass du dann wieder ne CPU hast die lahm ist. Denn die Atome von damals waren auch verglichen mit CPUs mit identischem Takt lahm.

Das echte Problem ist meiner Meinung nach die mangelnde Sicherheit.

Stell dir vor, du betreibst ein Rechenzentrum, das Webhostingdienste für viele verschiedene Firmen anbietet und die laufen alle in ihrer VM.
Spectre erlaubt, dass man aus den VM ausbrechen und die Informationen aller anderen Firmen einlesen kann.

Für einen solchen Webserverdienstleister und die Firmen die darauf angewiesen sind, ist das schliechtweg ein Supergau.

Das gleiche Problem dürfte bei Banken und sonstigen kritischen Infrastrukturen bestehen.

Mit dem Design des alten Atom könnte man hier recht schnell eine sichere CPU auf den Markt werfen.

Und wenn ich so einen Shop hätte, dann würde ich mir sogar einen alten Bladeserver mit Briarwood CPUs (also vom alten Atom) auf dem Gebrauchtmarkt kaufen und meinen Shop damit betreiben.
Dass es dann unter Umständen etwas langsamer wird, das kann schon sein, aber das ist noch längst nicht so schlimm wie Kosten die durch ein Datenleck anfallen könnten.

Die derzeit existierenden für Spectre anfälligen Out-of-Order CPUs sind einfach nicht mehr sicher und das ist IMO das wesentliche Problem.
Die paar Prozent Leistungsverlust sind nicht so schlimm, damit kann man durchaus leben, auch wenn es ein saurer Apfel ist, aber das ist noch einer den man essen kann. Eine unsichere CPU ist dagegen ein giftiger Apfel.

Und ich bin mir auch fast sicher dass man ähnliche Angriffe auch für Atom konstruieren kann. Vielleicht nur welche die lange nicht praktikabel sind, aber Timing-Unterschiede über die man an bestimmte "verbotene" Informationen kommen kann gibt es auch bei Atom CPUs.

Spectre funktioniert nur bei Out Of Order CPUs.
Der alte Atom ist eine In Order CPU.
Hier gibt's eine sehr gute Erklärung, wenn jemand im Bekanntenkreis fragt, die ist auch für Laien geeignet.
https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/

LOL, Jetzt wundert mich nichts mehr, warum die Presse "Lügenpresse" oder "Lückenpresse" genannt wird, so sieht Spectre und Meltdown bei der Presse aus:
https://pbs.twimg.com/media/DSxGaU_XcAAbVtx?format=jpg&name=small

Quelle:
https://www.heise.de/forum/heise-online/News-Kommentare/Linus-Torvalds-Will-Intel-Scheisse-fuer-immer-und-ewig-verkaufen/Lest-lieber-wie-sich-die-echten-Experten-der-Presse-ueber-Intel-empoeren/posting-31635878/show/

so ist das eben bei den sog. weichen wissenschaften

hustbaer

Lieber computertrolls, es geht beim Verzicht auf OOE und Speculative Execution um wesentlich mehr als nur "ein paar Prozent"*. Was das Sprengen von VM-Grenzen angeht muss ich erst nochmal nachlesen - bin mir nicht sicher ob das überhaupt geht bzw. ein reales Problem ist welches nicht mit Software-Patches zu beheben ist. (Ich glaube nämlich dass es kein reales Problem ist, aber ich will hier nix behaupten wo ich mir nicht sicher bin.)

Davon abgesehen: Was Spectre ist und wie es funktioniert brauchst du mir nicht zu erklären bzw. irgend eine Teletubby-Erklärung verlinken - ich habe das sehr gut verstanden. Ich nehme an wesentlich besser als du.

Auch was "ähnliche Angriffe" bedeutet scheint dir nicht so ganz klar zu sein.

Diskussionen mit dir sind manchmal schon einigermassen anstrengend.

*: Hier, damit du nen Eindruck bekommst um was es da geht: https://www.cpubenchmark.net/cpu.php?cpu=Intel+Atom+S1260+%40+2.00GHz

hustbaer schrieb:

Lieber computertrolls, es geht beim Verzicht auf OOE und Speculative Execution um wesentlich mehr als nur "ein paar Prozent"*.

Bei den paar Prozent bezog ich mich auf die Meltdown und Spectre fixes für die Out-of-Order CPUs.

Bezüglich den Pentium G (Skylake) habe ich jetzt etwas weiter recherchiert und herausgefunden, dass sie die gleiche Signatur haben wie bspw. mein i7-6700K.

Damit teilen sie sich auch den gleichen Microcode.