CVE-2025-6202 (SK Hynix DDR5)

[tollertyp]

@0x8100 Du hast damit bewiesen das lokaler Zugriff vorhanden sein muss.

Und du hast bewiesen, dass du von Beweisführung keine Ahnung hast.
Er hat einen Weg gezeigt, wie es getestet werden kann. Das ist kein Beweis, dass es nicht anders ausgenutzt werden kann. Und nur weil man etwas noch nicht gefunden hat, ist es kein Beweis dafür, dass es das nicht gibt.

Man kann nicht beweisen, dass es keinen Gott gibt. Man kann höchstens beweisen, dass einen gibt - wenn er gefunden wurde.

Dass es via Boot-Medium gemacht wird ist meiner Meinung nach auch nachvollziehbar, weil es bei dem Test nur um die Prüfung der technischen Anfälligkeit geht, und dabei sollte die verwendete Software keine Rolle spielen. Also wenn das Betriebssystem Mechanismen hat, die das Ausnutzen der Lücken verhindert, dann sollte das keine Auswirkung auf diese Prüfung haben.

Diese Prüfung macht ja keine Aussage über die konkrete Bedrohungslage für ein laufendes System, sondern zeigt, ob die Hardware selbst für den Angriff anfällig ist. Dem kann man aber mitunter softwareseitig eben auch gegensteuern.

Im GitHub-Projekt steht nicht grundlos, dass das Tool "a powerful resource for hardware security research" ist (Quelle: https://github.com/iisys-sns/FlippyRAM).

 

[Sensei21]

Der Themen-Titel ist missverständlich - es nicht nicht nur SK Hynix betroffen es ist Rowhammer anhand vom Beispiel von RAM von SK Hynix

dachte erst es wäre etwas besonders gravierendes, was SK Hynix betrifft

We demonstrate with Phoenix that all DDR5 devices from SK Hynix, currently the largest DRAM manufacturer, are still vulnerable to a new variant of Rowhammer attacks.

Do the results imply that DDR5 devices from other vendors are protected against Rowhammer?|
No, due to the extensive effort of reverse engineering the in-DRAM Rowhammer mitigations, we limited ourselves to devices from the largest DRAM manufacturer, SK Hynix.

 

[Salamimander]

Naja aber zumindest ist es, vorerst, für SK Hynix gefixt und der CVE Eintrag bezieht sich auch nur darauf.

 

[Sensei21]

Wirklich gefixt ist es nicht - es wird nur eine Lösung angeboten, da fast 10% schlechtere Leistung dabei herauskommt und das wird wahrscheinlich nicht jeder akzeptieren

 

[Salamimander]

Es ist mit dem AGESA Update behoben, siehe Startpost.

Quelle: Gigabyte (Siehe Screenshot)

 

[Sensei21]

steht irgendwo, wie das implementiert wurde ?

die AGESA changelogs sind häufig immer so spärlich an Informationen

 

[Salamimander]

Leider nein, entweder ganz stumpf über den refresh cycle oder deren pattern wurde geblacklistet. Beides nicht sonderlich nachhaltig