Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Spectre und Meltdown: All unsere…

Verstehe das Geschrei nicht

  1. Thema

Neues Thema Ansicht wechseln


  1. Verstehe das Geschrei nicht

    Autor: Dudeldumm 05.01.18 - 13:58

    Um auf die CPU-mem zugreifen zu können, brauche ich doch wohl eine Software, die bereits auf dem Rechner installiert ist und entsprechenden Zugriff hat.
    Dasselbe ist wahr für zB einen Keylogger. Der ist viel einfacher zu bauen und liefert zusätzlich nur relevante Daten.
    Wobei auch noch das Gerücht umgeht, dass gängige OS eh schon Hintertürchen für die 99999999 Ami-Geheimdienste eingebaut haben.

    Denke, dass die Angreifbarkeit über SW jetzt schon so gross ist, dass ein sehr hypothetischer, super-komplexer Angriff über die HW irrelevant ist.

  2. Re: Verstehe das Geschrei nicht

    Autor: CoDEmanX 05.01.18 - 14:07

    Installiert sein muss sie nicht. Du könntest ein entsprechendes Programm runterladen und ausführen, oder von einem USB-Stick aus ausführen oder ähnliches. Möglich ist auch eine Ausnutzung durch JavaScript - also den bloßen Aufruf einer Website. Es muss nicht Mal die Website selbst sein, die präparierten ist. Es könnte auch durch eine Werbeanzeige eines Drittanbieters auf der Seite kommen, per XSS-Angriff usw. Siehe dazu auch Rowhammer.

  3. Re: Verstehe das Geschrei nicht

    Autor: Dudeldumm 05.01.18 - 14:13

    JavaScript läuft in der virtuellen Maschine des Browsers.
    Kann mir auch mit viel Fantasie nicht vorstellen, wie ich von da aus auf den Prozessorcache zugreifen können soll.
    Sorry, das is totaler Käse.
    Was das Ausführen von Code angeht... nunja, da sind wir wieder beim Keylogger, oder anders gesagt, alles viel einfacher möglich.

  4. Re: Verstehe das Geschrei nicht

    Autor: CoDEmanX 05.01.18 - 14:58

    Ob du dir das vorstellen kannst oder nicht, es geht.

    https://www.react-etc.net/entry/exploiting-speculative-execution-meltdown-spectre-via-javascript

    Und verwandt Rowhammer:

    https://github.com/IAIK/rowhammerjs
    https://media.ccc.de/v/34c3-9135-aslr_on_the_line

  5. Re: Verstehe das Geschrei nicht

    Autor: Dudeldumm 05.01.18 - 16:35

    Hab mir das Ding angetan.
    Ich habe verstanden, dass man mit JavaScript im Browser (sowie mit jeder anderen Programmiersprache auch), die CPU 'verleiten' kann, ein Datum eines anderen Prozesses in den Cache zu legen, ohne eine Exception auszulösen.
    Aber das wars doch dann. Ich kann nicht mit JS auf diesen Cache zugreifen. Oder hab ich was übersehen?

  6. Re: Verstehe das Geschrei nicht

    Autor: MarioWario 05.01.18 - 17:24

    Irgendwie hast Du ein paar Jahre verpasst: Die Antiviren-Hersteller haben vor langer Zeit bereits darauf hingewiesen das keine Dateien mehr geschrieben werden müssen (es gab auch schon infizierte Grafikkarten wo man den Code nicht aus dem Speicher bekommt).

    Alles was kein ECC-RAM eingebaut hat kann mit Rawhammer übernommen werden.

    Bei allen Core-i-Prozessoren funktioniert auch der ME-Minix-Downgrade-Backdoor/Bug.

    Natürlich ist auch USB über den Firmware-Trojaner oder auch RubberDucky zugänglich - eigentlich müßte die Plattform TRASH 2018 heißen.

  7. Re: Verstehe das Geschrei nicht

    Autor: CoDEmanX 05.01.18 - 18:05

    Ein konkretes Angriffsszenario mit Rowhammer ist IIRC einen Bitflip an einer bestimmten Stelle zu bewirken, um z.B. einen Pointer zu manipulieren oder eine Sicherung wie das Execution Bit auszuschalten: https://de.wikipedia.org/wiki/NX-Bit

  8. Re: Verstehe das Geschrei nicht

    Autor: Epaminaidos 05.01.18 - 20:48

    Dudeldumm schrieb:
    --------------------------------------------------------------------------------
    > Hab mir das Ding angetan.
    > Ich habe verstanden, dass man mit JavaScript im Browser (sowie mit jeder
    > anderen Programmiersprache auch), die CPU 'verleiten' kann, ein Datum eines
    > anderen Prozesses in den Cache zu legen, ohne eine Exception auszulösen.
    > Aber das wars doch dann. Ich kann nicht mit JS auf diesen Cache zugreifen.
    > Oder hab ich was übersehen?

    Computerphile hat eine halbwegs brauchbare Erklärung (https://www.youtube.com/watch?v=I5mRwzVvFGE).

    Kurz und knapp:
    1.) Man verleitet die CPU dazu, einen unzulässigen Wert aus dem Speicher zu lesen.
    2.) Genau dieser unbekannte Wert wird verwendet, um auf ein eigenes Array zuzugreifen.
    Anschließend stellt die CPU fest, dass sie das alles gar nicht hätte tun dürfen und verwirft die Ergebnisse wieder.
    ABER:
    Als Seiteneffekt liegt ein Wert aus dem eigenen Array nun nicht mehr nur im Arbeitsspeicher, sondern auch im CPU-Cache.

    Und jetzt kommt der Seitenkanalangriff:
    Die Anwendung prüft, wie schnell sie auf die einzelnen Werte des eigenen Arrays zugreifen kann. Im Idealfall sind alle langsam (100ns), nur der eine aus Schritt 2 kommt besonders schnell (<1ns), da er im CPU-Cache liegt.
    Damit hat man den Index, auf den in Schritt 2 zugegriffen wurde und damit auch den unbekannten Wert.



    2 mal bearbeitet, zuletzt am 05.01.18 21:02 durch Epaminaidos.

  9. Re: Verstehe das Geschrei nicht

    Autor: Dudeldumm 05.01.18 - 21:22

    Epaminaidos schrieb:
    --------------------------------------------------------------------------------
    > Dudeldumm schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Hab mir das Ding angetan.
    > > Ich habe verstanden, dass man mit JavaScript im Browser (sowie mit jeder
    > > anderen Programmiersprache auch), die CPU 'verleiten' kann, ein Datum
    > eines
    > > anderen Prozesses in den Cache zu legen, ohne eine Exception auszulösen.
    >
    > > Aber das wars doch dann. Ich kann nicht mit JS auf diesen Cache
    > zugreifen.
    > > Oder hab ich was übersehen?
    >
    > Computerphile hat eine halbwegs brauchbare Erklärung (www.youtube.com
    >
    > Kurz und knapp:
    > 1.) Man verleitet die CPU dazu, einen unzulässigen Wert aus dem Speicher zu
    > lesen.
    > 2.) Genau dieser unbekannte Wert wird verwendet, um auf ein eigenes Array
    > zuzugreifen.
    > Anschließend stellt die CPU fest, dass sie das alles gar nicht hätte tun
    > dürfen und verwirft die Ergebnisse wieder.
    > ABER:
    > Als Seiteneffekt liegt ein Wert aus dem eigenen Array nun nicht mehr nur im
    > Arbeitsspeicher, sondern auch im CPU-Cache.
    >
    > Und jetzt kommt der Seitenkanalangriff:
    > Die Anwendung prüft, wie schnell sie auf die einzelnen Werte des eigenen
    > Arrays zugreifen kann. Im Idealfall sind alle langsam (100ns), nur der eine
    > aus Schritt 2 kommt besonders schnell (<1ns), da er im CPU-Cache liegt.
    > Damit hat man den Index, auf den in Schritt 2 zugegriffen wurde und damit
    > auch den unbekannten Wert.

    Das stimmt bis auf den letzten Satz. Der ist falsch.
    Wenn ich auf einen Wert ausserhalb meines Adressraums zugreifen könnte (ohne anderes, aufwändiges Gedöns, und das ist nur mit C/C++ möglich, keinesfalls aus einer virtuellen Maschine heraus (JavaScript, Browser), wenn überhaupt noch heutzutage dank OS), dann bräuchte Ich das ganze Zeug gar nicht. Ich mache einfach einen Null-Zeiger und hole mir alles danach, Stück für Stück. Ob ich das also mit BYTE b= *(myPointer++); oder BYTE b= myArray[index++]; mache, ist egal, wird eh gleich compiliert.

    Das Problem in dem verlinkten Artikel ist, dass nirgendwo erklärt wird, wie ich an die Daten im cache komme, aber das ist doch die Quintessenz, denn nur dort liegt die Info vom 'VictoimProcess'. Wenn das nicht geht, ist das alles egal.
    Lasse mich gerne andersweitig überzeugen, aber so generelle Unzulänglichkeiten der heutigen Zugriffe auf RAM (row hammer) sind da ein bisschen dünn. Vllt hab ichs ja übersehen im Artikel?

  10. Re: Verstehe das Geschrei nicht

    Autor: Epaminaidos 06.01.18 - 00:18

    Dudeldumm schrieb:
    --------------------------------------------------------------------------------
    > Lasse mich gerne andersweitig überzeugen, aber so generelle
    > Unzulänglichkeiten der heutigen Zugriffe auf RAM (row hammer) sind da ein
    > bisschen dünn. Vllt hab ichs ja übersehen im Artikel?

    Ich versuch's mal, lasse mich aber auch gern überzeugen, wenn ich etwas falsch verstanden habe.

    Für den Angriff ist es vollkommen schnurz, ob der geschützte Wert im Cache liegt oder nicht. Der Trick läuft anders.

    Pseudo-Code:
    var a1 = new byte[1];
    var a2 = new byte[256];
    var target = 1234567; //oder eine andere hohe Zahl.
    if (target < a1.length) {
    var x = a2[a1[target]];
    }
    for(var n=0;n<a2.length;n++){
    //Zeitmessung des Zugriffs auf a2[n]
    }

    Moderne Prozessoren führen teilweise Code im "if" spekulativ aus, während sie auf die Auswertung der Bedingung warten. Schlägt das "if" dann etwas später fehl, werden die Ergebnisse der spekulativen Ausführung einfach wieder verworfen.
    Die spekulative Ausführung hat aber einen Nebeneffekt:
    Nur mal angenommen, im angegriffenen Byte steht die Zahl 25. Dann ist nach der spekulativen Ausführung der Wert von a2[25] im CPU-Cache.
    Greift man also auf a2[25] zu, ist der Zugriff wesentlich schneller als auf einen anderen Wert, der aus dem RAM geholt werden muss. Und dafür ist dann die Schleife da: Sie misst für jeden Index von a2 die Zugriffszeit und findet den Index mit der kürzesten Zugriffszeit: 25. Und das ist gerade der eigentlich geschützte Wert.

    Das ist natürlich alles nur Pseudo-Code zur Erklärung des Prinzips. In der Praxis ist das sicher nicht ganz so einfach :-)



    3 mal bearbeitet, zuletzt am 06.01.18 00:21 durch Epaminaidos.

  11. Re: Verstehe das Geschrei nicht

    Autor: Bradolan 06.01.18 - 06:33

    Dudeldumm schrieb:
    --------------------------------------------------------------------------------
    > JavaScript läuft in der virtuellen Maschine des Browsers.
    > Kann mir auch mit viel Fantasie nicht vorstellen, wie ich von da aus auf
    > den Prozessorcache zugreifen können soll.
    > Sorry, das is totaler Käse.
    > Was das Ausführen von Code angeht... nunja, da sind wir wieder beim
    > Keylogger, oder anders gesagt, alles viel einfacher möglich.

    https://www.youtube.com/watch?v=ewe3-mUku94&t=1796
    Damit findet man schonmal die Adresse von JS Objekten raus. Vllt noch irgendein Objekt mit überlauffähig wählen und es kann losgehen.



    1 mal bearbeitet, zuletzt am 06.01.18 06:43 durch Bradolan.

  12. Re: Verstehe das Geschrei nicht

    Autor: mnementh 06.01.18 - 10:36

    Dudeldumm schrieb:
    --------------------------------------------------------------------------------
    > JavaScript läuft in der virtuellen Maschine des Browsers.
    > Kann mir auch mit viel Fantasie nicht vorstellen, wie ich von da aus auf
    > den Prozessorcache zugreifen können soll.
    > Sorry, das is totaler Käse.
    Öhm, die Browserhersteller patchen gegen den totalen Käse, weil, nun ja es funktioniert.
    https://www.golem.de/news/spectre-und-meltdown-browserhersteller-patchen-gegen-sidechannel-angriff-1801-131972.html

  13. Re: Verstehe das Geschrei nicht

    Autor: Tet 06.01.18 - 14:06

    Dudeldumm schrieb:
    --------------------------------------------------------------------------------
    > Hab mir das Ding angetan.
    > Ich habe verstanden, dass man mit JavaScript im Browser (sowie mit jeder
    > anderen Programmiersprache auch), die CPU 'verleiten' kann, ein Datum eines
    > anderen Prozesses in den Cache zu legen, ohne eine Exception auszulösen.
    > Aber das wars doch dann. Ich kann nicht mit JS auf diesen Cache zugreifen.
    > Oder hab ich was übersehen?

    Der Trick besteht nicht darin, die CPU dazu zu bringen, Daten anderer Prozesse in den Cache zu legen. Er besteht darin, mit diesen Daten anderer Prozesse eine Rechenoperation auszuführen und anhand des Ergebnisses Daten in ein Array für den eigenen Prozess in den Cache zu legen. Danach greift man auf das Datenarray zu und prüft mittels Zeitmessung, welcher Wert sich schon zuvor im Cache befand. Daraus kann man dann schließen, was der Inhalt des Speicherbereichs ist, auf den man nicht zugreifen kann.

  14. JavaScript-Monster

    Autor: Anonymer Nutzer 06.01.18 - 18:02

    .

    Ist es nicht JavaScript dass dafür sorgt
    dass der Aufruf einer Webpage
    gleich 0,5 Gigabyte Arbeitsspeicher ver'ram'scht?

    .

  15. Re: Verstehe das Geschrei nicht

    Autor: Dudeldumm 07.01.18 - 12:14

    Epaminaidos schrieb:
    --------------------------------------------------------------------------------
    > Dudeldumm schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Lasse mich gerne andersweitig überzeugen, aber so generelle
    > > Unzulänglichkeiten der heutigen Zugriffe auf RAM (row hammer) sind da
    > ein
    > > bisschen dünn. Vllt hab ichs ja übersehen im Artikel?
    >
    > Ich versuch's mal, lasse mich aber auch gern überzeugen, wenn ich etwas
    > falsch verstanden habe.
    >
    > Für den Angriff ist es vollkommen schnurz, ob der geschützte Wert im Cache
    > liegt oder nicht. Der Trick läuft anders.
    >
    > Pseudo-Code:
    > var a1 = new byte[1];
    > var a2 = new byte[256];
    > var target = 1234567; //oder eine andere hohe Zahl.
    > if (target < a1.length) {
    > var x = a2];
    > }
    > for(var n=0;n<a2.length;n++){
    > //Zeitmessung des Zugriffs auf a2
    > }
    >
    > Moderne Prozessoren führen teilweise Code im "if" spekulativ aus, während
    > sie auf die Auswertung der Bedingung warten. Schlägt das "if" dann etwas
    > später fehl, werden die Ergebnisse der spekulativen Ausführung einfach
    > wieder verworfen.
    > Die spekulative Ausführung hat aber einen Nebeneffekt:
    > Nur mal angenommen, im angegriffenen Byte steht die Zahl 25. Dann ist nach
    > der spekulativen Ausführung der Wert von a2[25] im CPU-Cache.
    > Greift man also auf a2[25] zu, ist der Zugriff wesentlich schneller als auf
    > einen anderen Wert, der aus dem RAM geholt werden muss. Und dafür ist dann
    > die Schleife da: Sie misst für jeden Index von a2 die Zugriffszeit und
    > findet den Index mit der kürzesten Zugriffszeit: 25. Und das ist gerade der
    > eigentlich geschützte Wert.
    >
    > Das ist natürlich alles nur Pseudo-Code zur Erklärung des Prinzips. In der
    > Praxis ist das sicher nicht ganz so einfach :-)


    Ok, das würde Sinn ergeben. Ich teste also jedes mögliche Byte (0-255) und messe die Zugriffszeit und speichere alle 'richtigen' Bytes in meinem stream. Ok, so verstanden macht's Sinn.

  16. Re: Verstehe das Geschrei nicht

    Autor: Dudeldumm 07.01.18 - 12:18

    mnementh schrieb:
    --------------------------------------------------------------------------------
    > Dudeldumm schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > JavaScript läuft in der virtuellen Maschine des Browsers.
    > > Kann mir auch mit viel Fantasie nicht vorstellen, wie ich von da aus auf
    > > den Prozessorcache zugreifen können soll.
    > > Sorry, das is totaler Käse.
    > Öhm, die Browserhersteller patchen gegen den totalen Käse, weil, nun ja es
    > funktioniert.
    > www.golem.de

    Seit menschengemachter Klimaerwärmung, bösen Arabern, 9/11, Ukraine usw glaub ich nix mehr. Kann genausogut sein, dass man der Panikwelle nachgibt und lieber mit Reklame dagegenhält statt mit Aufklärung gegen Windmühlen kämpft.
    Jaja, Aluhut und Fisch, schon klar.

  17. Re: Verstehe das Geschrei nicht

    Autor: Bachsau 21.01.18 - 04:30

    ><///(°>

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Bosch Gruppe, Reutlingen
  2. Grand City Property, Berlin
  3. über duerenhoff GmbH, Raum Bremen
  4. NRW.BANK, Münster

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Blu-ray-Angebote


Haben wir etwas übersehen?

E-Mail an news@golem.de


NGT Cargo: Der Güterzug der Zukunft fährt 400 km/h
NGT Cargo
Der Güterzug der Zukunft fährt 400 km/h

Güterzüge sind lange, laute Gebilde, die langsam durch die Lande zuckeln. Das soll sich ändern: Das DLR hat ein Konzept für einen automatisiert fahrenden Hochgeschwindigkeitsgüterzug entwickelt, der schneller ist als der schnellste ICE.
Ein Bericht von Werner Pluta


    Serverless Computing: Mehr Zeit für den Code
    Serverless Computing
    Mehr Zeit für den Code

    Weniger Verwaltungsaufwand und mehr Automatisierung: Viele Entwickler bauen auf fertige Komponenten aus der Cloud, um die eigenen Anwendungen aufzubauen. Beim Serverless Computing verschwinden die benötigten Server unter einer dicken Abstraktionsschicht, was mehr Zeit für den eigenen Code lässt.
    Von Valentin Höbel

    1. Kubernetes Cloud Discovery inventarisiert vergessene Cloud-Native-Apps
    2. T-Systems Deutsche Telekom will Cloud-Firmen kaufen
    3. Trotz hoher Gewinne Wieder Stellenabbau bei Microsoft

    Job-Porträt Cyber-Detektiv: Ich musste als Ermittler über 1.000 Onanie-Videos schauen
    Job-Porträt Cyber-Detektiv
    "Ich musste als Ermittler über 1.000 Onanie-Videos schauen"

    Online-Detektive müssen permanent löschen, wo unvorsichtige Internetnutzer einen digitalen Flächenbrand gelegt haben. Mathias Kindt-Hopffer hat Golem.de von seinem Berufsalltag erzählt.
    Von Maja Hoock

    1. Software-Entwickler CDU will Online-Weiterbildung à la Netflix
    2. Bundesagentur für Arbeit Ausbildungsplätze in der Informatik sind knapp
    3. IT-Jobs "Jedes Unternehmen kann es besser machen"

    1. Apple: iPad Pro 2018 soll leicht verbiegen
      Apple
      iPad Pro 2018 soll leicht verbiegen

      Das iPad Pro 2018, das Apple erst vor wenigen Wochen vorgestellt hat, soll einigen Berichten zufolge besonders leicht verbiegen.

    2. Smartphone: Google soll Pixel 3 Lite mit Kopfhörerbuchse planen
      Smartphone
      Google soll Pixel 3 Lite mit Kopfhörerbuchse planen

      Bekommt Googles Pixel-Smartphone wieder einen Kopfhöreranschluss? Ein russisches Blog hat Fotos veröffentlicht, die eine vereinfachte Version des Pixel 3 zeigen sollen. Ob es sich auf den Fotos um ein echtes Pixel 3 Lite handelt, ist aber unklar.

    3. Akkuzellfertigung: Volkswagen legt noch 10 Milliarden Euro drauf
      Akkuzellfertigung
      Volkswagen legt noch 10 Milliarden Euro drauf

      Volkswagen will für die Umstellung auf Elektroautos jetzt nicht nur 34 Milliarden, sondern gleich 44 Milliarden Euro investieren. Der Grund: Den Wolfsburgern fehlen Akkuzellen.


    1. 12:55

    2. 12:25

    3. 11:48

    4. 10:46

    5. 09:00

    6. 00:02

    7. 18:29

    8. 16:45