News ZenHammer: Auch Ryzen und Epyc lassen den „Bit Flip“ per Rowhammer zu

Gibt's auch ein sicheres Testtool für Intel-CPUs für diesen und andere Hacks?
 
aid0nex schrieb:
Bit Flips sind wie korrekt beschrieben ja eine physikalische Sicherheitslücke im RAM. Warum genau ging man dann der Annahme dass der RAM sicher ist wenn er mit AMD Zen Prozessoren betrieben wird? Ich hätte erwartet dass erstmal jede CPU davor nicht sicher ist.

Ich fand die Aussage, dass es eine Annahme gibt, dass Zen-Prozessoren sicher seien, auch ueberraschend. Meine Erinnerung sagt, dass bei frueheren Rowhammer-Artikeln den Forschern mit einem vor-Zen-AMD-Memory-Controllern kein Angriff gelungen ist (oder so), weil der damalige Memory Controller deutlich weniger Zugriffe zusammengebracht hat als der damalige Intel-Memory-Controller. Ich vermute, mit Double-Rowhammer (eine Verfeinerung von Rowhammer) haette (oder hat es?) es trotzdem geklappt, und AMD hat den Memory Controller mit Zen deutlich verbessert, um mehr Bandbreite aus dem Speicher zu bekommen, was aber auch die Anfaelligkeit fuer Rowhammer erhoeht.

Ich denke im Konkreten wird es für den einzelnen Endanwender ein weniger schlimmes Problem sein, da der Angriff schon sehr spezifisch und angepasst sein muss.

Darauf wuerde ich mich nicht verlassen. Solche Anpassungen an konkrete Hardware kann man in ein Werkzeug stecken, das dann die richtige Variante fuer die Maschine des Ziels ausfuehrt. So viele Memory Controller und so viele Speichervarianten gibt's ja bei PCs nicht.
 
  • Gefällt mir
Reaktionen: aid0nex
@mae Gut möglich, aber dann ist das ja nur eine Erfolglosigkeit im Praktischen, deswegen ist der Chip in der Theorie nicht sicher - und dreht man ein zwei Parameter in der Praxis um, ist auch ein praktischer Angriff erfolgreich wie man sieht. ;) Und klar, du hast Recht, verlassen würde ich mich darauf auch nicht. Wie man sieht konnte man sich ja auch nicht darauf verlassen dass Zen Chips sicher sind. :D
 
Ich seh das so:
Wenn jemand eines meiner Systeme rowhammern kann, dann ist es sowieso schon zu spät.

Und mit einem gekarperten Container rowhammer Attacken auf andere gekapselte Systeme aufführen um eine IBAN zu verändern für kriminelle Überweisungen?
In der Praxis völlig unmöglich.

Einzelne Bits flippen, ja, Daten dadurch zerstören ja, aber sicher nicht irgendwas sinnvolles auslesen oder verändern.
Das wäre ja wie wenn man angeblich von Festplatten nach dem Überschreiben noch Daten auslesen kann. Man muss für ein 20KB PNG halt 160.000 Mal in Folge 60/40 raten.
Bei rowhammer wäre es 160.000 Mal blind raten ohne zu wissen an was man eigentlich rätselt.
 
  • Gefällt mir
Reaktionen: ComputerJunge
jusaca schrieb:
Nicht wirklich, außer du vermietest auf deinem Privatrechner VM-Instanzen nach außen. Die meisten dieser Sicherheitslücken werden relevant, wenn auf einer Maschine parallel mehrere fremde Instanzen laufen, ansonsten ist ja nicht wirklich was zum auslesen vorhanden.
Daher betrifft das tendenziell eher Server, auf denen man sich mit einer VM einmieten kann.
Nicht ganz. Theoretisch kann man auch auf deinem Rechner Geheimnisse auslesen. Aber da der Schadcode in diesem Fall auf deinem Rechner laufen muss wäre es eh schon egal. Weil dann kann ich auch ganz anderen Schadcode bei dir laufen lassen.
 
Wobei das ja wirklich eine physische Seitenkanalattacke ist, welche durch Software hervorgerufen wird. Mal abgesehen von Malware: wer weiß ob nicht auch normale Anwendungssoftware solche Schreibzugriffe verwendet, welche zu Bitfips in den Speicherzellen führen? Irgendwo müsste der Controller dieses physische Phänomen aus meiner Sicht schon berücksichtigen und beherrschen. Ich würde fast behaupten, das könnte man auch mit einem JavaScript in irgend einer Weise hervorrufen, wobei die Erfolgsquote damit rapide sinken wird. Aber wenn das funktionieren sollte, dann geht davon schon eine Alltagsgefahr aus.
 
Zuletzt bearbeitet:
Wenn es ein Hardwarespezifisches Problem beim RAM ist dann ist absolut jede Plattform betroffen. Nur weil die CPU Architekturen sich unterscheiden heißt es nicht, dass der RAM sicher ist. Selbst ARM CPUs sollten, mit der richtigen Angriffsmethode, zum Bitflip gebracht werden können. Ich könnte mir sogar vorstellen, dass man auch Grafikkarten dazu bringen kann.

Ich halte die praktische Gefahr aber für äußerst gering und das die theoretische Möglichkeit eines Angriffszenarios seit bereits einem Jahrzehnt besteht bestärkt mich in der Annahme.
In dem speziellen Fall hier muss immer eine Anpassung auf die CPU Architektur stattfinden und dann muss der Angreifer auch noch Glück haben, dass der Bitflip rechtzeitig stattfindet und dann auch noch verwertbare Daten extrahiert werden können.

Am einfachsten dürfte ein Angreifer es bei Gamingstable OC Kisten haben und am schwersten bei gut gesicherten Servern.
Da gibt es andere Methoden die eine höhere Erfolgswahrscheinlichkeit haben und gewinnbringender sind. Die größte und einfachste Sicherheitslücke ist immer noch unsere menschliche Dummheit.
 
  • Gefällt mir
Reaktionen: drSeehas
DaZpoon schrieb:
Wobei das ja wirklich eine physische Seitenkanalattacke ist, welche durch Software hervorgerufen wird. Mal abgesehen von Malware: wer weiß ob nicht auch normale Anwendungssoftware solche Schreibzugriffe verwendet, welche zu Bitfips in den Speicherzellen führen?

Es sind nicht nur Schreibzugriffe. Bei jedem Lesen findet ein Refresh der Zeile statt, der die umgebenden Zeilen beeinflusst.

Man weiss, dass normale Software das nicht macht, weil das Phaenomen nur bei der Rowhammer-Software beobachtet wurde. Wenn das bei der Anwendungssoftware XY auftreten wuerde, dann haetten Benutzer gemeldet, dass Systeme mit XY Probleme mit der Stabilitaet haben, und dann hatten die Softwareentwickler das Problem entdeckt.

Zum Vergleich: Es gab so einen Fall, wo WIMRE Intel-Prozessoren Code, der vom Ocaml-Compiler erzeugt wurde, nicht korrekt ausfuehren konnten. Obwohl Ocaml keine besonders populaere Programmiersprache ist, ist das aufgefallen, und wurde dann untersucht, und hat zu einem Fix von Intel ueber Microcode-Patches gefuehrt (der auch ein bisschen Performance kostet).
Ergänzung ()

iPain schrieb:
Wenn es ein Hardwarespezifisches Problem beim RAM ist dann ist absolut jede Plattform betroffen. Nur weil die CPU Architekturen sich unterscheiden heißt es nicht, dass der RAM sicher ist. Selbst ARM CPUs sollten, mit der richtigen Angriffsmethode, zum Bitflip gebracht werden können. Ich könnte mir sogar vorstellen, dass man auch Grafikkarten dazu bringen kann.

Natuerlich geht das. Bei Grafikkarten dachte ich im ersten Moment, dass das ja egal ist, wenn in den Grafikdaten ein paar Bits umfallen. Aber man koennte auch Programmbits passend aendern, und die Grafikprogramme duerfen ueber PCIe in das CPU-RAM schreiben und koennen dabei gut Schaden anrichten. Eventuell wird noch durch die IOMMU begrenzt, wohin die Grafikkarte schreiben kann, aber ob die immer richtig programmiert ist, ist die Frage.

Ich halte die praktische Gefahr aber für äußerst gering und das die theoretische Möglichkeit eines Angriffszenarios seit bereits einem Jahrzehnt besteht bestärkt mich in der Annahme.

Die theoretische Moeglichkeit bestand schon laenger, vor 10 Jahren wurde erstmal praktisch demonstriert, dass das moeglich ist, und seither immer wieder. Man kann den Kopf in den Sand stecken, und darauf hoffen, dass das niemand ausnutzt, und klar, solange man keine Hardware bekommt, die nicht betroffen ist, bleibt einem da wenig anderes uebrig. Aber man sollte trotzdem regelmaessig bei den RAM-Herstellern und Prozessorherstellern nachfragen, wann sie endlich einen Fix fuer Rowhammer bringen, und dann, wenn die das tun, das auch in die Kaufentscheidung einfliessen lassen.
 
Zuletzt bearbeitet:
Das hat nichts mit Kopf in den Sand stecken zu tun.
Meine Einschätzung beruht auf der Tatsache, dass bisher noch niemand diese Lücke aktiv ausnutzen konnte.
Es gibt viele Lücken die man unter Laborbedingungen nutzen kann aber aus denen sich kein praktisches Angriffsszenario bauen lässt.
Bisher ist dies bei der Lücke der Fall. Oder kennst du auch nur einen Fall aus der Praxis bei der diese Lücke sinnvoll und zielgerichtet eingesetzt werden konnte?
Unter Laborbedingungen konnte man dafür sorgen, dass ein Bitflip stattfindet aber du kannst weder dir gezielt aussuchen welches Bit umspringt noch kannst du garantieren, dass du daraus kapital schlagen kannst.
Also ist es praktisch unter bestimmten Bedingungen machbar aber weiterhin nur theoretisch im Alltag nutzbar.
Deswegen schrieb ich auch explizit, dass es sich hierbei um ein theoretisches Angriffsszenario handelt.
Labor und Alltag sind zwei komplett unterschiedliche paar Schuhe und sollten niemals in einer 1zu1 Beziehung gebracht werden.

Das heißt aber natürlich nicht, dass die Hersteller die Füße hochlegen können. Der Fehler muss behoben werden weil es jederzeit passieren kann, dass jemand einen Weg finden diese Lücke im Alltag auszunutzen.
 
Ich habe mich schon seit Ewigkeiten nicht mehr damit beschaeftigt, aber wird moderner RAM noch linear adressiert, oder ist da heutzutage auch eine gewisse Zufaelligkeit mit im Spiel?
Evtl. verwechsel ich es, aber ALSR macht sowas doch eigendlich, das Speicher quasi zufaellig adressiert wird, richtig?

Das alleine sollte ja schon dafuer sorgen, das die meisten Angriffe dieser Art es sehr schwer haben nutzbare Daten zu bekommen.
Ansonsten, aber dafuer muesste man ALSR fuer sichere Bereiche deaktivieren, muesste es ja eigendlich auch helfen, sichere Bereiche groesser zu definieren, so das man die wirklich sicheren Daten tatsaechlich physikalisch abgrenzen kann. In der Regel sind die wirklich kritischen Daten (Kryptokeys) ja eher klein, so dass das in der Grundlast untergehen duerfte wenn man den benoetigen Speicher einfach mal, sagen wir, verzehnfacht.
 
iPain schrieb:
Meine Einschätzung beruht auf der Tatsache, dass bisher noch niemand diese Lücke aktiv ausnutzen konnte.

Wie kommst Du darauf? Schon 2016 konnte man mit Rowhammer Android-Smartphones rooten.

Es gibt viele Lücken die man unter Laborbedingungen nutzen kann aber aus denen sich kein praktisches Angriffsszenario bauen lässt.
Bisher ist dies bei der Lücke der Fall. Oder kennst du auch nur einen Fall aus der Praxis bei der diese Lücke sinnvoll und zielgerichtet eingesetzt werden konnte?

Siehe oben.

Unter Laborbedingungen konnte man dafür sorgen, dass ein Bitflip stattfindet aber du kannst weder dir gezielt aussuchen welches Bit umspringt

Gerade das geht recht gut. Die Schwierigkeit liegt darin, herauszufinden, welchen virtuellen Speicher man wie fuellen und dann staendig refreshen muss, um die gewuenschten bits im Ziel umkippen zu lassen. Aber wie das Android-Beispiel zeigt, gibt es auch dafuer Moeglichkeiten.

Das heißt aber natürlich nicht, dass die Hersteller die Füße hochlegen können. Der Fehler muss behoben werden weil es jederzeit passieren kann, dass jemand einen Weg finden diese Lücke im Alltag auszunutzen.

Eigentlich reicht es, wenn man die Maer unter die Leute bringt, dass es eine rein theoretische oder hoechstens unter Laborbedingungen ausnutzbare Luecke ist, wozu die Hardware fixen?
Ergänzung ()

Ranayna schrieb:
Ich habe mich schon seit Ewigkeiten nicht mehr damit beschaeftigt, aber wird moderner RAM noch linear adressiert, oder ist da heutzutage auch eine gewisse Zufaelligkeit mit im Spiel?

Durch virtuellen Speicher ist es nicht offensichtlich, welche physische Speicheradressen den vom User-Level-Programm verwendeten (virtuellen) Adressen entsprechen. Da ist nicht unbedingt der Zufall im Spiel, aber tatsaechlich weiss man das im Normalfall nicht. Das heisst nicht, dass Angreifer keine Moeglichkeiten haben, das herauszufinden.

Evtl. verwechsel ich es, aber ALSR macht sowas doch eigendlich, das Speicher quasi zufaellig adressiert wird, richtig?

ASLR bewirkt, dass im virtuellen Adressraum die Speicherallokationen zufaellige Adressen bekommen. Es kann aber leicht passieren, dass eine Speicherseite dann zwar eine andere virtuelle Adresse, aber dieselbe physische Adresse bekommt als ohne ASLR. Und Rowhammer arbeitet auf physischem RAM. Also nein, ASLR macht das nicht.

muesste es ja eigendlich auch helfen, sichere Bereiche groesser zu definieren, so das man die wirklich sicheren Daten tatsaechlich physikalisch abgrenzen kann.

Wenn man tatsaechlich verhindern kann, dass Angreifer nicht Refreshes auf die (bei DDR4 ca. 4) Zeilen neben allen moeglichen Zielzeilen ausloesen koennen, dann hat man zumindest diese Zeilen gegen Rowhammer immunisiert. Das Problem dabei ist, dass es sehr viele moegliche Zielzeilen gibt, das sind ja nicht in erster Linie die Bereiche, wo die Schluessel drinnen sind, sondern z.B. beliebiger Programmcode, der irgendwann ausgefuehrt wird, und der durch bitflips so geaendert wird, dass z.B. die geheimen Schluessel in der Ausgabe des Programms aufscheinen. Offenbar ist so eine Mitigation unrealistisch, sonst haetten die Hardwarehersteller die Betriebssystemhersteller schon dazu gedraengt, sowas in die Betriebssysteme einzubauen.
 
Zuletzt bearbeitet:
Zurück
Oben