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. via 3C - Career Consulting Company GmbH, Frankfurt am Main
  2. ASK Chemicals GmbH, Hilden
  3. signTEK GmbH & Co. KG, Mannheim
  4. SV Informatik GmbH, Stuttgart

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (Filme und Musik - über 80.000 Artikel)
  2. (u. a. Mainboards, CPUs, Speicher, Grafikkarten, Gehäuse)
  3. 111,00€
  4. mit Gutscheincode PLAYTOWIN (max. 50€ Rabatt) - z. B. ASUS ROG Strix GeForce RTX 2070 Advanced...


Haben wir etwas übersehen?

E-Mail an news@golem.de


IT-Jobporträt Spieleprogrammierer: Ich habe mehr Code gelöscht als geschrieben
IT-Jobporträt Spieleprogrammierer
"Ich habe mehr Code gelöscht als geschrieben"

Wenn man im Game durch die weite Steppe reitet, auf Renaissance-Hausdächern kämpft oder stundenlang Rätsel löst, fragt man sich manchmal, wer das alles in Code geschrieben hat. Ein Spieleprogrammierer von Ubisoft sagt: Wer in dem Traumjob arbeiten will, braucht vor allem Geduld.
Von Maja Hoock

  1. Recruiting Wenn die KI passende Mitarbeiter findet
  2. Softwareentwicklung Agiles Arbeiten - ein Fallbeispiel
  3. IT-Jobs Ein Jahr als Freelancer

Radeon VII im Test: Die Grafikkarte für Videospeicher-Liebhaber
Radeon VII im Test
Die Grafikkarte für Videospeicher-Liebhaber

Höherer Preis, ähnliche Performance und doppelt so viel Videospeicher wie die Geforce RTX 2080: AMDs Radeon VII ist eine primär technisch spannende Grafikkarte. Bei Energie-Effizienz und Lautheit bleibt sie chancenlos, die 16 GByte Videospeicher sind eher ein Nischen-Bonus.
Ein Test von Marc Sauter und Sebastian Grüner

  1. Grafikkarte UEFI-Firmware lässt Radeon VII schneller booten
  2. AMD Radeon VII tritt mit PCIe Gen3 und geringer DP-Rate an
  3. Radeon Instinct MI60 AMD hat erste Grafikkarte mit 7 nm und PCIe 4.0

Enterprise Resource Planning: Drei Gründe für das Scheitern von SAP-Projekten
Enterprise Resource Planning
Drei Gründe für das Scheitern von SAP-Projekten

Projekte mit der Software von SAP? Da verdrehen viele IT-Experten die Augen. Prominente Beispiele von Lidl und Haribo aus dem vergangenen Jahr scheinen diese These zu bestätigen: Gerade SAP-Projekte laufen selten in time, in budget und in quality. Dafür gibt es Gründe - und Gegenmaßnahmen.
Von Markus Kammermeier


    1. Streaming: Netflix zahlt in deutsche Filmförderung ein
      Streaming
      Netflix zahlt in deutsche Filmförderung ein

      Netflix beendet den Rechtsstreit und zahlt einen Umsatzanteil an die deutsche Filmförderung. Die Filmabgabe, die neben den Kinos von der Videowirtschaft und dem Fernsehen erhoben wird, sollen nun alle Streaminganbieter zahlen.

    2. Netzbetreiber: Ericsson und Nokia könnten Huawei nicht ersetzen
      Netzbetreiber
      Ericsson und Nokia könnten Huawei nicht ersetzen

      Ein führender europäischer Netzbetreiber fürchtet um seinen 5G-Ausbau, sollte Huawei ausgeschlossen werden. Die beiden europäischen Ausrüster könnten hier nicht so einfach einspringen. Auch die GSMA warnt eindringlich.

    3. Ubuntu-Sicherheitslücke: Snap und Root!
      Ubuntu-Sicherheitslücke
      Snap und Root!

      Über einen Trick kann ein Angreifer Ubuntus Paketverwaltung Snap vorgaukeln, dass ein normaler Nutzer Administratorrechte habe - und damit wirklich einen Nutzer mit Root-Rechten erstellen.


    1. 19:17

    2. 18:18

    3. 17:45

    4. 16:20

    5. 15:42

    6. 15:06

    7. 14:45

    8. 14:20