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

[mae]

Aber würde das nicht ECC generell als Schlangenöl erscheinen lassen?
also wenn das wirklich auch mit (echtem, nicht nur DDR5-Stütz-) ECC klappt

ECC korrigiert einzelne Bitflips in einem 32-bit-Bereich (bei DDR5 mit ECC) und meldet zwei Bitflips in so einem Bereich zuverlaessig. Bei drei oder mehr Bitflips kann es sein, dass das Ergebnis wie ein korrekter (aber anderer) Inhalt ausschaut. Das Szenario, gegen das ECC schuetzen soll, ist das zufaellige Umfallen von Bits z.B. durch kosmische Strahlung.

Bei Rowhammer koennen aber mehrere Bits in einem Bereich innerhalb kurzer Zeit zum Umfallen gebracht werden, und damit schuetzt ECC nicht (oder nur mit Glueck) vor Rowhammer.

Das on-die-ECC von DDR5 arbeitet m.W. mit groesseren Bereichen, aber da gilt grundsaetzlich das gleiche; der Nachteil, den on-die-ECC hat, naemlich dass die Uebertragung nicht geschuetzt wird, spielt fuer Rowhammer keine Rolle. Der groessere Bereich macht es allerdings wohl fuer den Angreifer ein bisschen einfacher.

 

[Hito360]

erwartunugsgemaesses AMD Bashing obwohl auch Intel betroffen und Quelle eigentlich "zu dichter" DRAM ist?

 

[foofoobar]

So oder so ist der aktuelle ECC halt auf eine bestimmte Anzahl an Flips ausgelegt. Man kann sicher natürlich (und es ist auch mathematisch trivial) einen ausdenken, der gegenüber mehr Flips resistent ist oder einen, der gegen weniger resistent ist und jeweils dann entsprechend mehr oder weniger Kosten hervorruft.

Da Daten vom DRAM mittlerweile nur noch in großen Blöcken (Burst) gelesen werden könnte man die FEC mit anderen und besseren Verfahren sichern.
Generell kann eine FEC mit größeren Datenmengen effizienter und besser arbeiten.

 

[Findus]

Bei Rowhammer koennen aber mehrere Bits in einem Bereich innerhalb kurzer Zeit zum Umfallen gebracht werden, und damit schuetzt ECC nicht (oder nur mit Glueck) vor Rowhammer.

Mein Gedanke war jetzt nicht speziell auf einen Angriff im bezogen, das Verhalten liese sich ja theoretisch auch mit "regulärer" Nutzung erreichen, wenn man nur ein ähnliches Nutzungsprofil hätte wie es der Angriff vorgibt
Statt gewollter Daten hat man dann leider Datensalat in seinem Körbchen

 

[cvzone]

damit ist diese Unterscheidung hinfällig.

Manche Angriffe sind aber derart aufwändig und nur unter Laborbedingungen möglich, sodass sie für Privatanwender quasi keine Relevanz haben, weil kein Angreifer die sich die Mühe macht oder gar nicht Möglichkeiten (physischen Zugang) hat.

 

[ComputerJunge]

damit ist diese Unterscheidung hinfällig.

Der Unterschied ergibt sich aus der Eintrittswahrscheinlichkeit. Die halte ich zumindest bei einem Privatanwender für signifikant bis exorbitant geringer. "Versichern" kann man sich ja dennoch.

 

[Draco Nobilis]

weil kein Angreifer die sich die Mühe macht oder gar nicht Möglichkeiten (physischen Zugang) hat.

Mmmmh wäre ich ein Konzern(Bayer, Siemens, Airbus etc.) oder der Staat würde ich schon was dagegen machen wollen.
Aber ja normal gibt es zig andere lohnendere Zugänge.

Man könnte sich aber als Firmengruppe in der Tat mal zusammensetzen um das Problem nach inzwischen 10 Jahren gemeinsam anzugehen.

 

[mae]

Mein Gedanke war jetzt nicht speziell auf einen Angriff im bezogen, das Verhalten liese sich ja theoretisch auch mit "regulärer" Nutzung erreichen, wenn man nur ein ähnliches Nutzungsprofil hätte wie es der Angriff vorgibt
Statt gewollter Daten hat man dann leider Datensalat in seinem Körbchen

Ja, aber offenbar gibt's dieses Benutzungsprofil in der Praxis nur bei Angriffen, zumindest sind solche Effekte nur den Sicherheitsforschern aufgefallen, die das absichtlich herbeigefuehrt haben. Wenn Datensalat bei ansonsten funktionierender Hardware ein signifikantes Problem der regulaeren Benutzer waere, waeren die DRAM- und Speichercontrollerhersteller sicher williger, etwas dagegen zu tun. So ist es ja nur eine Sicherheitsluecke, wo die Hersteller (und andere) dann damit beschwichtigen, dass potentielle Angreifer lieber eine andere Luecke ausnutzen.

 

[sNo0k]

heruntergelassene Hosen

heruntergelassene Hosenheit !

 

[foofoobar]

Der Unterschied ergibt sich aus der Eintrittswahrscheinlichkeit. Die halte ich zumindest bei einem Privatanwender für signifikant bis exorbitant geringer. "Versichern" kann man sich ja dennoch.

Bei Systemen die von Laien konfiguriert werden hältst du die Eintrittswahrscheinlichkeit für geringer?
Ich nicht.

Und die Privat-Kisten haben im Regelfall kein ECC.

 

[Hannibal Smith]

@foofoobar Es geht ja auch nicht darum, dass es nicht möglich wäre oder kein Risiko darstellt, sondern ehr in die Richtung, dass man mit einem Generalschlüssel für alle Schlösser wohl auch ehr in Richtung Bank und weniger zu den normalos geht um einzusacken.

Dennoch ist hier einmal mehr der Beweis erbracht, dass nichts sicher ist.
Und damit auch die Bestätigung, dass gerade die Cloud ein erhöhtes Risiko darstellen kann. (Auch wenn sehr viele das nicht sehen wollen)
Natürlich gilt das auch für Virtualisierungsumgebungen aller Art, nur kann man ein System, dass man vollständig unter seiner Kontrolle hat und das nicht mit fremden geteilt wird, deutlich besser absichern und behandeln.

 

[ComputerJunge]

@foofoobar
Ja, weil ich sie (in der Rolle "Mensch mit eigenem lokalen Computer") für ein uninteressantes Angriffsziel via dieser Methode halte. Zumindest nach meinem Verständnis zum notwendigen hohen Aufwand für eine gleichzeitig nicht vorhersagbare "Ernte".

 

[DerBär88]

Ist das wirklich schon so lange her ?

Ja seit 2010 gilt: Multi-Bit ECC

Ein kurzen Praktischen Test laufen lassen:

Test 13 [Hammer Test]

The row hammer test exposes a fundamental defect with RAM modules 2010 or later. This defect can lead to disturbance errors when repeatedly accessing addresses in the same memory bank but different rows in a short period of time. The repeated opening/closing of rows causes charge leakage in adjacent rows, potentially causing bits to flip.

This test 'hammers' rows by alternatively reading two addresses in a repeated fashion, then verifying the contents of other addresses for disturbance errors. For more details on DRAM disturbance errors, see Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors by Yoongu Kim et al.

Starting from MemTest86 v6.2, potentially two passes of row hammer testing are performed. On the first pass, address pairs are hammered at the highest possible rate. If errors are detected on the first pass, errors are not immediately reported and a second pass is started. In this pass, address pairs are hammered at a lower rate deemed as the worst case scenario by memory vendors (200K accesses per 64ms). If errors are also detected in this pass, the errors are reported to the user as normal. However, if only the first pass produces an error, a warning message is instead displayed to the user.

https://www.memtest86.com/tech_individual-test-descr.html

Das Thema hat sich für mich erledigt.

 

[bad_sign]

Wie vergleichbar ist den Rowhammer vs den üblichen RAM Testern (Karhu, Prime95, Linpack, Memtest, y-cruncher)

 

[DerBär88]

Der Test # 13 ist Bestandteil der Memtest86 Test Suite und wird als letzter durchgeführt.

So etwas in Form von µ-Code zu erstellen erfordert sehr viel wissen über EMI und wie Magnetfelder Miteinander Interagieren.

Das wissen wie das im Detail funktioniert, sollte nicht in die Falschen Hände geraten. (Speicher aus spionieren)

Edit:

 

[Marmormacker]

Ach, dafür ist der Test also da? Lustig, lasse Memtest recht häufig durchlaufen wenn ich vermute, dass irgendein System instabil ist. Tatsächlich gab es da bei Test 13 noch nie einen Fehler, bei den von mir getesteten System. Meist waren Probleme schon nach ein paar Sekunden offensichtlich.

 

[DerBär88]

Das ist unser Ziel, weniger Zeit in Hardware defekte zu investieren und schneller Probleme aufdecken.

Dabei hat man nicht immer Zuspruch, sondern auch mächtig Gegenwind.

Mehr RAM oder VRAM bedeutet immer mehr Einflüsse von Außen.

Ein Spieler, sollte spielen könne wie er es mag.

Die Entwickler, sind am Drücker.

 

[Breaktivity]

Ich würde annehmen, dass der Hammer Test in MemTest86 anders als die Veröffentlichung nicht auf Zen-Cores angepasst ist und entsprechend hier keine wirkliche Aussagekraft hat. Die Autoren der Veröffentlichung haben ja auch ein für Intel Skylake effektives Rowhammer-Tool (Blacksmith) getestet, und das hat auf Zen 2 wenige und auf Zen 3 keine Bit Flips hinbekommen.

Als Privatanwender würde ich mir ohnehin kaum Gedanken machen, da der Angriff eher unzuverlässig ist, oft lange dauert und (korrigiert mich, wenn ich falsch leige) aus dem Browser heraus in JavaScript mangels zuverlässiger Zeitmessung, Informationen zu Speicheradressen und zur Konfiguration des Systems umso mehr unrealistisch erscheint.
Mit ECC wird der Angriff zwar auch nicht unmöglich, aber (noch) esoterisch(er). Mit verschlüsseltem Speicher im Server dürfte am Ende auch nicht mehr als Denial of Service rauskommen.

 

[aid0nex]

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 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. Das ist eher ein Problem für lohnenswerte Ziele wie große Hoster oder andere Firmen.

 

[mae]

Wie vergleichbar ist den Rowhammer vs den üblichen RAM Testern (Karhu, Prime95, Linpack, Memtest, y-cruncher)

Prime95 und y-cruncher sind CPU-intensive Programme, nicht RAM-Tests. Karhu kenne ich nicht. Bei Memtest86 greifen die klassischen Tests auf den gesamten Speicher zu und verteilen damit die Zugriffe auf viele Zeilen, waehrend eine Rowhammer-Attacke nur auf wenige Zeilen zugreift (die physisch in der Naehe der attackierten Zeile liegen).