Diskussion:Spectre (Sicherheitslücke)

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Allgemeinverständlichkeit 

message: 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)
replies: text: nennr sich bei mir ScriptBlock, wird aber nicht die einzige derartige Erweiterung sein.--Lectorium (Diskussion) 07:02, 19. Jan. 2018 (CET)
thread_title:  Gegenmaßnahmen 

message: Der Pale Moon Brauser ist immun und kann daher bedenkenlos eingesetzt werden: - https://forum.palemoon.org/viewtopic.php?f=1&t=17928 
: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)
thread_title:  Pale Moon 

message: 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)
replies: text: 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)
thread_title:  "Spectre Next Generation" 

message: 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?!
: 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)
thread_title:  Feedback, Wunsch und Frage 

message: :Würde das nicht Sinn machen?
:-- CleveresKerlchen • Nachricht senden • Wikiliebe 22:26, 29. Jun. 2019 (CEST)
replies: text: Mit Spectre haben sie jedenfalls quasi nix zu tun... --Dgruss (Diskussion) 00:36, 29. Jan. 2020 (CET)
thread_title:  Zombieload und Store-to-Leak in eigene Artikel auslagern