Diskussion:Spectre (Sicherheitslücke)

Allgemeinverständlichkeit

Ich weiß, es geht um ein aktuelles Ereignis und es bestand noch keine Zeit dazu, den Text so zu formulieren, dass auch Menschen ohne muttersprachliche Assemblerkenntnisse das Problem einigermaßen nachvollziehen können. Langfristig sollte das meiner Meinung nach aber nicht so bleiben. Bitte nicht. ~ ToBeFree (Diskussion) 18:40, 5. Jan. 2018 (CET)

Full Ack! Das braucht aber seine Zeit um das technische Zeug in - vor allem richtige! - nicht technische Worte zu fassen. Etwas Geduld bitte. --WikiPimpi (Diskussion) 18:54, 5. Jan. 2018 (CET)

Gerne, danke euch allen schonmal für die Mühe! Ich hatte vor der Diskussions-Bitte überlegt, einige Sätze umzuformulieren, aber dabei ist mir die Schwierigkeit bewusst geworden. :) ~ ToBeFree (Diskussion) 19:12, 5. Jan. 2018 (CET)

Beim "Kommentierten Quelltext" ist auch einiges durcheinandergeraten, da mag man nicht mehr lesen. (nicht signierter Beitrag von 134.101.135.210 (Diskussion) 3. Mai 2018, 23:06:32‎)

Gegenmaßnahmen

Wie sieht es mit dem InternetExplorer und Edge aus dem Hause Microsoft aus? Werden die auch irgendwann gehärtet oder sind die immun?

Kommt mit dem nächsten Windows-Patch für IE und Edge: https://blogs.windows.com/msedgedev/2018/01/03/speculative-execution-mitigations-microsoft-edge-internet-explorer/ --WikiPimpi (Diskussion) 20:57, 8. Jan. 2018 (CET)

"... Ferner kann das Verwenden einer Browser-Erweiterung, welche aktive Inhalte wie JavaScript blockiert, das Risiko minimieren (z. B. NoScript für Firefox oder SaveScript für Chrome)." Ich habe nirgendwo eine Erweiterung namens SaveScript gefunden auch die Suchmaschinen geben nichts dazu her.

Bitte an die üblichen Gepflogenheiten sich halten und die Beiträge signieren! Sollte nicht so schwer sein. Auch ist hier keine Auskunft, hier soll nur um den Artikel gehen. Vermutlich ist ScriptSafe gemeint, ich werde dies mal ändern "save-script" wäre ja auch eher gaga, "rette das script"? (save = retten, sparen, speichern etc. - safe = sicher, gefahrlos etc.) -- WikiMax - 17:20, 8. Jan. 2018 (CET)

nennr sich bei mir ScriptBlock, wird aber nicht die einzige derartige Erweiterung sein.--Lectorium (Diskussion) 07:02, 19. Jan. 2018 (CET)

Pale Moon

Der Pale Moon Brauser ist immun und kann daher bedenkenlos eingesetzt werden: - https://forum.palemoon.org/viewtopic.php?f=1&t=17928(nicht signierter Beitrag von 94.220.76.107 (Diskussion) 16:13:43, 09 Januar 2018)

Bedenkenlos täte ich gar nichts einsetzen. Von Pale Moon habe ich noch nie gehört. Ich halte jedenfalls zu Firefox, auch da soll es ja angeblich Patches geben, die Spectre Exploits per JavaScript verbieten sollen. Bis dahin sollte jedoch NoScript reichen, da damit auch JavaScript verboten wird. Das heißt, solange der Anwender es nicht wieder bei jeder "dahergelaufenen" Webseite einschaltet... ‣Andreas•⚖ 18:30, 10. Jan. 2018 (CET)

"Spectre Next Generation"

Forscher haben acht neue Sicherheitslücken in Intel-Prozessoren gefunden, die hälftig von Intel als hochriskant eingestuft wurden. Die Ursache ist dasselbe Prozessordesign-Problem. Es steht eine never ending Patch-Flut bevor, weil Intel vor zwanzig Jahren alle Entwicklungen ohne ausreichendes Sicherheitskonzept umgesetzt hat. Ein Kritikabschnitt an diesem chronisch unsicheren CPU-Design ist überfällig, wäre aber im Intel-Artikel besser aufgehoben, oder? --Lectorium (Diskussion) 12:23, 4. Mai 2018 (CEST)

Jetzt wart doch mal ab, was diese Lücken genau sind, und ob jemand tatsächlich diese Lücken auf wissenschaftliche Art auf ein grundsätzlich "unsicheres Design" zurückführt. Denn Wikipedia ist eine Enzyklopädie und bildet Wissen ab, sie ist (ihrer Bestimmung nach) keine Meinungsplattform. Bisher ist jedenfalls nur Out-of-Order-Execution als Ursache benannt, und die ist so ziemlich überall Stand der Technik für Performancegewinn, der Fix besteht darin, sie an bestimmten Stellen einfach abzuschaalten. Bei Meltdown ist das allerdings anders, weil es eine (durch OoOE ausgelöste) Privilege Escalation ist, gegen die eine CPU-Architektur grundsätzlich schützen muss.--Alturand…D 12:40, 4. Mai 2018 (CEST)

Spezial:Diff/179571469/179571704 - Meltdown und Spectre Abgrenzung

@Sivizius: - ich denke, Du irrst. Das Charakteristikum von Meltdown ist, dass eine Privilege Escalataion an den Schutzmechanismen des Prozessors (Adressspace-Separation) vorbei auftritt. Alle Spectre-Varianten beziehen sich auf den gleichen Adressraum und umgehen 'lediglich' Schutzmechanismen der Laufzeitumgebung. --Alturand…D 12:26, 30. Jul. 2018 (CEST)

Meltdown lässt sich tatsächlich nicht mit nicht-nativer Code, also beispielsweise mit JS, ausnutzen, da bei Meltdown eine Anweisung ausgeführt wird, die zwar als solche gültig ist, aber auf illegale Speicherbereiche zugreift (User und Kernel Space) und dann die nächste Operation spekulativ ausgeführt wird (sinnvollerweise eine Operation mit den illegal gelesenen Daten). Das gleiche kann ich aber auch mit Spectre in nativen Code erreichen: Auch dort kann ich auf Kernel Daten zugreifen, nur dass hier der Lesezugriff spekulativ erfolgt. Spectre und Meltdown wurden zusammen in einem Atemzug veröffentlicht, nur dass Spectre 1 und 2 von einer anderen Gruppe als Meltdown kam. Im Grunde sollte besser alles in einem Artikel über Sicherheitslücken der spekulativen Ausführung zusammengetragen werden und dort auch mal auf Spectre Variante 2 (darauf wird hier gar nicht mal eingegangen, hier ist nur Spectre Variante 1) und die neuen Spectre-Varianten (für die übrigens das Logo falsch ist, das ist nur für Variante 1 und 2) eingegangen werden. Auch unterscheidet sich beispielsweise Lazy FP state restore stärker von Spectre/Meltdown, als Spectre und Meltdown untereinander: Während letztere auf den Cache zugreifen, greift Ersteres auf ein Register zu. Wegen geringen Unterschieden zwischen Meltdown und Spectre diese zu unterscheiden, während trotz größerer Unterschiede Spectre und Spectre NG zusammengefasst werden, ist nicht sinnvoll. Gemein ist jedenfalls allen, dass hier Sicherheitslücken der spekulativen Ausführung moderner Prozessoren ausgenutzt werden. – Sivizius (Diskussion) 14:02, 30. Jul. 2018 (CEST)

@Sivizius: Hmmm....Die Gemeinsamkeit der spekulativen Ausführung ist unbestritten, aber den Rest sehe ich anders: ich versuche das mal, auseinander zu divdieren:

• Spectre attacks involve inducing a victim to speculatively perform operations that would not occur during correct program execution and which leak the victim’s confidential information via a side channel to the adversary. This paper describes practical attacks […] that can read arbitrarymemory from the victim’s process. gegenüber Meltdown exploits side effects of out-of-order execution on modern processors to read arbitrary kernel-memory locations…. Da (in den Originalveröffentlichungen) steht eigentlich schon, was den Unterschied ausmacht: Spectre liest „arbitrary memory from the victim's process“, Meltdown liest „arbitrary kernel-memory locations“. Jedenfalls in den Originalveröffentlichungen. Aus welcher Quelle entnimmst Du, dass die Ausnutzung einer Spectre-Lücke Dir Zugriff auf Kernel-Daten gibt, die nicht ohnehin in den Adressraum des Angriffsprozesses gemapped sind?
• „Von einer anderen Gruppe“...Paul Kocher, Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, Michael Schwarz, Yuval Yarom ...habe ich in beiden Autorenlisten der Erstveröffentlichungen gefunden - und keine Autoren, die nur bei Spectre oder Meltdown mitgewirkt haben. Was genau führt jetzt dazu, dass dieselben Leute eine andere Gruppe bilden? Ich gehe mal davonaus, dass dieselben Leute einen Grund hatten, zwei Paper zu schreiben und die Grenze zwischen Meltdown und Spectre so zu ziehen, wie sie es in den Papern gemacht haben.
• „Meltdown lässt sich tatsächlich nicht mit nicht-nativer Code, also beispielsweise mit JS, ausnutzen,…“? Nach nochmaliger Lektüre des Originalpapers sieht das für mich so aus als ob lediglich eine Exception notwendig ist, um den Prozessor dazu zu verleiten, Code "hinter" der Exception spekulativ im privilegierten Modus auszuführen. Warum sollte ich mit nicht-nativem Code (Z.B: Java Bytecode) keine Exception hinbekommen?

Bleiben also fürs Erste mal zwei Fragen:

1. Welches Paper WP:Q zeigt, dass man mit einer Spectre-Lücke Kernel Speicher auslesen kann und somit die Differenzierung darüber nicht erfolgen kann?
2. Welches Paper WP:Q zeigt, dass es sich bei beiden Sicherheitslücken eigentlich um dieselbe Lücke handelt, weil es innerhalb der Lücken größere Unterschiede gibt als zwischen den Lücken?

--Alturand…D 18:44, 30. Jul. 2018 (CEST)

Feedback, Wunsch und Frage

Hallo allerseits, erstmal Glückwunsch für den 2. Absatz bei der Erklärung: Das ist die beste und kompakteste die ich dazu bisher gelesen habe :-) Was mir im Artikel allerdings noch fehlt, ist die Beschreibung von Gegenmaßnahmen, insbes. von aktualisierten Compilern. Und dazu dann auch gleich eine Frage: Was sollen neue Compiler da denn bringen? Wenn ich jetzt der böse Mann bin, der Spectre ausnutzen will, nehme ich doch dann den alten Compiler?!(nicht signierter Beitrag von 89.14.121.2 (Diskussion) 23. Aug. 2018, 18:22:06)

Was die Gegenmaßnahmen angeht hast Du teilweise recht. Die ersten Versionen von Spectre ermöglichten es, dass ein Programm auf Speicherzbereiche zugreift, auf die es normalerweise nicht in diesem Kontext zugreifen würde. Das Beispiel von JavaScript im Browser ist dafür das eingängigste: Normalerweise gilt die Annahme, dass JavaScript-Code nur auf Elemente des JavaScript-Programms, bzw. spezifizierte Elemente der Umgebung, wie das HTML-DOM zugreifen kann. Interne Zustände des Interpreters oder des Browsers, in dem der Interpreter läüft, sollten nicht zugreifbar sein. In Folge von Spectre kann man aber JavaScript-Code schreiben, der bei Ausführung durch den Interpreter den Heap und Stack des Browsers (z.B. mit gespeicherten Cookies oder Passwörtern) ausliest. Spectre ist deshalb so brisant, weil man einen Browser einfach dazu bekommen kann, JavaScript-Code nachzuladen, denn das ist die Aufgabe des Browsers auf vielen Webseiten. Der Interpreter, der den JavaScript-Code interpretiert, ist aber Bestandteil des Browsers und wird normalerweise mit diesem in Binärform ausgeliefert. Daher gibt es die Möglichkeit, den Browser mit einem "therapeutischen" Compiler zu bauen, so dass die Spectre-Lücken nicht mehr ausnutzbar sind, weil der Compiler an kritischen Stellen Gegenmaßnahmen in den Binärcode einfügt.

Bei Software, die Du selbst kompilierst und auf Deinem PC ausführst, ist Spectre (in den ursprünglichen Varianten) nicht so bedeutsam, weil das von Dir geschriebene Programm ja sowieso auf seinen gesamten Speicher zugreifen darf. Erst die neueren Varianten ermöglichen es, ähnlich wie Meltdown für den Kernel, auf Speicher anderer Prozesse zuzugreifen. Da kann natürlich ein lokaler Angreifer, der bösartigen Code mit einem alten Compiler übersetzt und dann ausführt, die Lücke ausnutzen und somit bspw. Speicher eines anderen Prozesses, oder einer anderen virtuellen Maschine auf derselben Hardware, auslesen.--Alturand…D 19:22, 23. Aug. 2018 (CEST)

An Y2kbug

Hi.

Wegen dem hier:

Ich habe das hier geändert, weil das geschützt sich gemäß diesem schlechten Satzbau auf NetSpectre bezog.

Ein Angriff kann nicht geschützt werden, sondern abgemildert oder verhindert.

Ob man (also Bspw. ein Client) aber durch die beschriebenen Maßnahmen vor NetSpectre geschützt ist konnte ich nicht beurteilen, deshalb habe ich lediglich den unsinnigen Satz sinnig gemacht.

Beste Grüße -- CleveresKerlchen • Nachricht senden • Wikiliebe 03:12, 29. Jun. 2019 (CEST)

Okay. Habe ich angepasst. ‣Andreas•⚖ 13:01, 29. Jun. 2019 (CEST)

Schön. ^_^

-- CleveresKerlchen • Nachricht senden • Wikiliebe 22:29, 29. Jun. 2019 (CEST)

Zombieload und Store-to-Leak in eigene Artikel auslagern

Würde das nicht Sinn machen?

-- CleveresKerlchen • Nachricht senden • Wikiliebe 22:26, 29. Jun. 2019 (CEST)

Mit Spectre haben sie jedenfalls quasi nix zu tun... --Dgruss (Diskussion) 00:36, 29. Jan. 2020 (CET)

Keine Erwähnung der Problematik im Artikel Intel

Der verfügt generell über keinen Kritik-Abschnitt, ebenso wenig wie die anderen Hersteller bei denen ähnliche Probleme bekannt sind (AMD).

Zum navigieren siehe: Kategorie:CPU-Hersteller

-- CleveresKerlchen • Nachricht senden • Wikiliebe 22:28, 29. Jun. 2019 (CEST)

Naja, es ist ja so dass bestimmte Technologien wie Out-of-order execution und Speculative execution anfällig sind. Da muss man immer unterscheiden ob da ein Herstellerversagen oder ein Technologieversagen vorliegt. Im Zweifel muss man sich die Quellen anschauen. Und die nächste Frage ist dann welches Gewicht dem beigemessen wird. Generell ist es ratsam eine gewisse Portion Weitsicht zu haben und zu verglichen wie relevant sein Thema mit anderen Dingen ist, die schon im Artikel stehen. --TheRandomIP (Diskussion) 00:06, 30. Jun. 2019 (CEST)

Sicher ist das Technologieversagen, aber der Hersteller hat diese Technologie ja eingebaut eventuell sogar selbst (mit)entwickelt.

Die Tatsache dass es eine anthropogenen Klimaerwärmung durch diverse Technologien gibt entschuldigt ja auch nicht die ungebremste Produktion dieser klimaschädlichen Technologie.

Was meinst du in der Hinsicht mit Weitsichtigkeit?

Das der "Befall" mit diesen Sicherheitslücken sehr weite Teile der gesamten Produktpalette von Intel abdeckt?

Beste Grüße -- CleveresKerlchen • Nachricht senden • Wikiliebe 17:51, 30. Jun. 2019 (CEST)

Gleichzeitig würdest du aber auch nicht in den Firmen-Artikel jeder einzelner Firma dieser Welt, die CO2 ausstößt (alle?), eine Kritik zu dieser Firma wegen Klimawandels einstellen. Das meine ich mit Weitsicht. Betrachte die Dinge aus einer Entfernung und sei nicht so sehr nur auf ein einziges Thema / diese Sicherheitslücke fokussiert.

Vor allem da es so viele Hersteller betrifft (weit mehr als AMD und Intel) frage ich mich ob das ein geeigneter Kritikpunkt ist, den man für jede einzelne Firma schreiben soll. Ich denke eher nicht. Bei Intel ist die Besonderheit vielleicht die große mediale Wahrnehmung. Da kann man sich Dinge wie Imageverlust, einbrechende Verkauszahlen, etc. anschauen und sie in den Geschichts-Abschnitt einfügen. --TheRandomIP (Diskussion) 18:25, 30. Jun. 2019 (CEST)

Doch würde ich, denn dann wären die Artikel erst neutral.

Es gibt massenhaft Artikel in der Wikipedia, die sich wie Werbetexte lesen, eben weil jegliche Kritik fehlt.

Spectre und Meltdown und deren Nachfolger (so sie denn ausgegliedert werden) sollten mindestens in den Artikeln der betroffenen Hersteller verlinkt sein, aber sie werden nicht einmal erwähnt und das obwohl sie die bisher schlimmsten Hardware Sicherheitslücken sind die es seit Erfindung des Computers gab!

Ich finde das ziemlich weitreichend und daher von mir auch ziemlich weitsichtig.

;-p

Beste Grüße -- CleveresKerlchen • Nachricht senden • Wikiliebe 03:32, 2. Jul. 2019 (CEST)