Diskussion:Meltdown (Sicherheitslücke)

Sicherheitslücke mit Logo?

Wer erfindet den sowas. --Eingangskontrolle (Diskussion) 08:54, 4. Jan. 2018 (CET)

Logos are designed by Natascha Eibl. --Smial (Diskussion) 14:01, 4. Jan. 2018 (CET)

Das ist doch inzwischen Standard für größere Lücken. Vgl. Heartbleed. --Phiarc (Diskussion) 20:48, 4. Jan. 2018 (CET)

Abschnitte Ursachen/Lösung

Diese sind in der derzeitigen Version weder omatauglich noch zielführend, sondern recht essayistisch angelegt. Das kann man so nicht sichten und auch nicht wikifizieren. --Smial (Diskussion) 14:05, 4. Jan. 2018 (CET)

Das konnte ganz offensichtlich sofort weg.

OmA-tauglichkeit wird schwierig, denn die OmA kann halt selten Assembler.

Leider kann ich das ich auch nicht qualizifiert bewerten was die IP 217.110.38.74 geschrieben hat und leider hat sie auch keinerlei Quellen angegeben.... -- itu (Disk) 15:23, 4. Jan. 2018 (CET)

Ich schließe mich dem an, die Stelle sollte noch einmal überarbeitet werden, und kann dann wieder erneut eingestellt werden. Als Schmierblatt eignet sich entweder diese Diskussionsseite hier oder der Benutzernamensraum. --TheRandomIP (Diskussion) 15:44, 4. Jan. 2018 (CET)

Ei des Kolumbus

Die Ausnutzung der Sicherheitslücke ähnelt dem Ei des Kolumbus. Ich verstehe nicht viel von Informatik, aber den Mechanismus finde ich trotzdem ziemlich logisch. Ist vorher keiner auf diese Idee gekommen? --Nov3rd17 (Diskussion) 21:40, 4. Jan. 2018 (CET)

Doch, die Idee hatten schon viele. Die Komponenten sind ja auch alle schon eine Weile lang bekannt. Aber in der IT ist der Weg von der Idee bis zur Umsetzung oft lang. Und nicht jeder kann sich leisten, ein paar Jahre lang zu arbeiten, nur für Ruhm und Ehre und in der Hoffnung, darauf aufbauend mal einen guten Job zu bekommen. Und die, die wissen, wie man damit richtig Geld verdient, die gehen nicht in die Öffentlichkeit. -- Alturand (Diskussion) 21:54, 4. Jan. 2018 (CET)

Bezug zu Spectre (Sicherheitslücke)

Den Bezug zu Spectre im Abschnitt Wirkungsweise uns Auswirkungen habe ich entfernt. Außer der ooo-Execution und dem hidden channel über den Cache haben die beiden Angriffe nicht viel gemeinsam (s. das Spectre-Paper). Spectre benötigt nicht den gesamten Adressraum abgebildet, da der Angriff sich nur auf den eigenen Adressraum bezieht. Spectre ist keine privilege escalation im Sinne des Betriebssystems, sondern ermöglicht eine privilege escalation innerhalb eines Adressraums dahingehend, dass interpretierter oder just-in-time compilierter Code auf den gesamten Adressraum des Interpreters/aufrufenden Prozesses zugreifen kann. -- Alturand (Diskussion) 08:30, 5. Jan. 2018 (CET)

Wenn der aufrufende Prozess die Rechte des Betriebssystems hat, hat Spectre dann Zugriff auf den ganzen Adressraum? --Nov3rd17 (Diskussion) 08:48, 5. Jan. 2018 (CET)

Nur auf den Adressraum, der in den Prozess gemapped ist. Bei Meltdown geht es nicht um Rechte, die aufgrund der Benutzerkennung (root/SYSTEM/kernel) vom Betriebssystem zugeteilt werden, sondern um Rechte, die die Hardware über die Memory Management Unit vergibt. Spectre ist keine Privilege Escalation im Sinne der Wardwar oder des Betriebssystems (s. Paper), sondern nur im Sinne des ausführenden Prozesses. Am Beispielcode im verlinkten Originalpaper kann man sehen, dass hier nur ein String ausgelesen werden kann, der ohnehin im Programm vorhanden ist. Der angreifende Code hat keine höheren Privilegien als der normale Programmablauf zulässt. Das Programm könnte auch einfach regulär auf diesen Speicher zugreifen - entweder über Auflösung des Sysmbols oder durch direktes Setzen der Zieladresse. Die Brisanz von Spectre kommt daher, dass "an sich unauffälliger Code", wie hier der Zugriff auf ein Array, der (s. Paper) auch in Java Script (s. Paper, auch von externer Quelle nachgeladen!) erfolgen kann, Zugriff auf den gesamten Adressraum des ausführenden Prozesses hat, obwohl eigentlich(!) dieser Zugriff durch das Interpretieren unterbunden werden sollte. -- Alturand (Diskussion) 10:13, 5. Jan. 2018 (CET)

Verdachtsmomente im Voraus

Im Dezember 2017 wurde gerätselt, warum der Chef von Intel Ende November trotz guter Unternehmensaussichten auffällig viele Aktien seines Unternehmens verkauft hatte: Intel's CEO Just Sold a Lot of Stock(Artikel auf fool.com com 19. Dezember 2017)
Dies ist erst mal bloß eine Auffälligkeit. Seit wann gibt es im Netz spezifischere Verdachtsmomente, dass die Intel-Prozessoren einen derartig gravierenden Designfehler haben? --Nov3rd17 (Diskussion) 11:00, 5. Jan. 2018 (CET)

Von wegen intel only bug

ARM macht da auch mit: [1]. Ohnehin wäre eine Formulierung ähnlich "Derzeit ist dieser Schwachestelle für Intel-prozessoren bestätigt, besser. --18:12, 5. Jan. 2018 (CET)

Dieser Abschnitt kann archiviert werden. --Alturand (Diskussion) 18:32, 5. Jan. 2018 (CET)

Hinweis auf Beziehung zwischen Register AL und RAX wäre hilfreich

Ohne den Hinweis kann man den ASM code nicht verstehen. Siehe z.B. https://software.intel.com/en-us/articles/introduction-to-x64-assembly

kleine Umformulierung macht es evtl. klarer

z.Zt.:
Angriffe auf die Meltdown-Lücke – wie auch Angriffe auf die Spectre-Lücke – nutzen aus, dass bei Prozessoren, die Out-of-order execution durchführen, Anweisungen vom Prozessor spekulativ ausgeführt werden können und sich dabei der Zustand des Systems verändert, selbst wenn das Ergebnis der spekulativen Ausführung verworfen wird. Diese Veränderungen, wie z. B. das Laden einer Speicherseite in den Cache, dienen als verdeckter Kanal, um Information aus dem Adressraum des angegriffenen Prozesses, die anders nicht zugänglich wäre, an ein empfangendes Programm zu übertragen.
Änderungsvorschlag:
Angriffe auf die Meltdown-Lücke – wie auch Angriffe auf die Spectre-Lücke – nutzen aus, dass bei Prozessoren, die Out-of-order execution durchführen, Anweisungen vom Prozessor spekulativ ausgeführt werden können und sich dabei der Zustand des Systems erkennbar verändert, selbst wenn das Ergebnis der spekulativen Ausführung verworfen wird. Diese erkennbaren Zustandsänderungen des Systems ermöglichen indirekt Rückschlüsse auf Informationen, die eigentlich nicht zugreifbar sein sollten.
Im Falle von Meltdown schlägt der initiale unzulässige Versuch, den Wert einer Kernelspeicher-Zelle direkt auszulesen, zu einem erwarteten Fehler. Meldown nutzt aber die trotzdem weiter laufende spekulative Ausführung der CPU, um den nicht direkt erhältlichen Wert der Kernelspeicher-Zelle in eine neue Speicher-Adresse umzuwandeln und als nächstes darauf zuzugreifen. Der beobachtbare Seiten-Effekt hiervon ist, daß die Speicherseite zu dieser Addresse in den Cache der CPU geladen wird. Durch das Design des Caches bedingt (s.u.) kann schließlich auf den ursprünglichen Wert der eigentlich interessierenden Kernelspeicher-Zelle geschlossen werden.
Solche "Transportwege", die ggf. über mehrere Ebenen indirekt Informationen transportieren, werden "verdeckter Kanäle" genannt bzw. die Informationen, die so transportiert werden, als "Seitenband-Informationen" bezeichnet.

Der Verweis "(s.u.)" auf notwendig zu wissende Details des CPU Cache Designs wäre dann noch zu ergänzen

Ich halte diese Umformulierungen für sehr gelungen. Allerdings sollte ggf. noch hervorgehoben werden, dass die Informationen nur durch die Beobachtung des zeitlichen Verhaltens gewonnen werden und nicht etwa durch eine direkte Offenlegung des Speicherinhaltes. Die Abgrenzung gegenüber einer Race Condition sollte ggf. erläutert werden. Schweigstill (Diskussion) 15:05, 14. Jan. 2018 (CET)

„…um den nicht direkt erhältlichen Wert der Kernelspeicher-Zelle in eine neue Speicher-Adresse umzuwandeln und als nächstes darauf zuzugreifen.…“ klingt für mmiuch noch etwa holprig. Wie wäre es mit: „um aus dem nicht direkt erhältlichen Wert der Kernelspeicher-Zelle eine neue Speicher-Adresse im Adressraum des Programms zu berechnen. Durch spekulativen Zugriff auf diese Adresse wird die dazugehörige Speicherseite in den Cache geladen. Durch eine Analyse des Caches kann das angreifende Programm auf den Inhalt der ursprünglichen Kernelspeicher-Zelle schließen“? -- Alturand (Diskussion) 17:18, 14. Jan. 2018 (CET)

Ich würde den Ausdruck spekulative Ausführung vermeiden. Bei Meltdown geht es um keine spekulative Ausführung sondern nur die out-of-order oder gar parallele Ausführung von Operationen die eigentlich seriell abgearbeitet werden sollten. Spekulation gibt es im Prozessor z.B. beim Ergebnis von Verzweigungen oder bei gelesenen oder geschriebenen Daten. -- Dgruss (Diskussion) 13:06, 4. Apr. 2018 (CEST)

Darüber können wir streiten, ob Code hinter einem Syscall "spekulativ" ausgeführt wird, in der Annahme, dass der Syscall nicht trappt. Es geht aber schon darum, dass Code ausgeführt wird, der bei regulärem Programmablauf nie erreicht würde. Welchen Begriff schlägst Du dafür vor? -- Alturand (Diskussion) 15:10, 4. Apr. 2018 (CEST)

Hier die Definition aus dem Intel Manual V1 - 2.2.1: "Speculative execution refers to the processor’s ability to execute instructions that lie beyond a conditional branch that has not yet been resolved, and ultimately to commit the results in the order of the original instruction stream." Folglich handelt es sich bei Meltdown und Spectre-v4 nicht um Speculative Execution. So ist der Begriff definiert.--Dgruss (Diskussion) 17:31, 27. Jun. 2018 (CEST)