CVE-2025-6202 (SK Hynix DDR5)

Salamimander

Rear Admiral
Registriert
Okt. 2019
Beiträge
5.123
Habt ihr das mitbekommen? Ist wohl in AGESA 1.2.8.0 gefixt.

https://nvd.nist.gov/vuln/detail/CVE-2025-6202


Hier noch mehr:
https://comsec.ethz.ch/research/dram/phoenix/

Zusammenfassung:
Auswirkungen und Exploits
Das Team testete 15 DDR5-DIMMs von SK Hynix (Herstellungszeitraum 2021–2024). Das Ergebnis: Alle Module waren verwundbar .
• Root-Zugriff: Es gelang den Forschern, eine Rechteausweitung (Privilege Escalation) über die sudo-Binary durchzuführen. Auf einem Standard-PC dauerte dies im Durchschnitt nur etwa 5 Minuten .
• Weitere Ziele: Auch RSA-Schlüssel (SSH-Authentifizierung) und Page-Table-Einträge konnten erfolgreich manipuliert werden.
• ECC hilft nicht: Selbst das in DDR5 integrierte On-Die ECC (Error Correction Code) konnte die Angriffe nicht stoppen, da sich Bit-Flips über die Zeit akkumulieren .
Gegenmaßnahmen
Da die betroffenen Hardware-Module nicht per Update geflickt werden können, bleibt als wirksame Mitigation derzeit nur eine Konfigurationsänderung:
• Erhöhung der Refresh-Rate: Eine Verdreifachung der Refresh-Rate (auf tREFI ≈ 1.3 us) verhinderte die Bit-Flips in den Tests. Dies führt jedoch zu einem Performance-Verlust von ca. 8,4% (gemessen in SPEC CPU2017) .

Auch andere Hersteller und DDR4 könnte (!) betroffen sein, da gibt es aber noch kein POC
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Sensei21, NameHere, Tornhoof und 2 andere
Ist halt rowhammer, du kannst implizit davon ausgehen dass alle betroffen sind, ab bestimmten settings. Dann werden die bekannten Angriffe gefixt und in zwei Jahren geht's von vorne los.
 
  • Gefällt mir
Reaktionen: up.whatever, Sensei21, konkretor und 5 andere
Hab davon noch nie gehört, spannend das Thema.
 
Wie erkläre ich das den OC-Leuten, das sie die tREFI nicht mehr auf 65535 hochschrauben sollen, sondern runter auf 3000-3500.^^
Weil die Experten wie immer das nicht erklären:
Kleinerer tREFI Wert= höhere Refresh-Rate (Produktiv System mit hoher Datenintegrität)
Höherer tREFI Wert = niedrigere Refresh-Rate (OC-Gamer und AIDA Latenz Fetischisten)

Ohne wirklichen Zugriff auf das System funktioniert das ganze eh nicht.
 
Zuletzt bearbeitet:
Salamimander schrieb:
Hab davon noch nie gehört, spannend das Thema.

Spannend. Da gab es richtige Glaubenskriege wieso man den Schutz davor nicht benutzen sollte. Vor allen Intel war mit massiven Performance-Einbrüchen belastet.

 
NameHere schrieb:
Ohne wirklichen Zugriff auf das System funktioniert das ganze eh nicht.
Yap. Und dazu muss das ganze lokal ausgeführt werden usw... und wenn lokal was ausgeführt wird, dann ist es eh meist schon sehr spät was Schutzmechanismen angeht.
 
@tollertyp Das hat man damals auch gesagt. Dann gab es die Angriffe im Webbrowser. Dann wurden die Browser umgebaut.

Um Meltdown oder Spectre auszunutzen, muss ein Angreifer messen, wie lange es dauert, einen bestimmten Wert aus dem Arbeitsspeicher zu lesen. Dazu ist ein zuverlässiger und genauer Timer erforderlich. Als Gegenmaßnahme haben alle wichtigen Browser die Auflösung von performance.now() verringert, um die Angriffe zu erschweren. Eine weitere Möglichkeit, einen Timer mit hoher Auflösung zu erhalten, ist die Verwendung eines SharedArrayBuffer. Der Puffer wird von einem dedizierten Worker verwendet, um einen Zähler zu erhöhen. Der Hauptthread liest diesen Zähler und verwendet ihn als Zeitgeber. Bis dahin haben Browser beschlossen, SharedArrayBuffer zu deaktivieren.

In der Quelle https://developer.chrome.com/blog/meltdown-spectre steht mehr dazu.

Oder was meinst du mit Lokal?
 
Ist das nicht schon wieder so eine Sicherheitslücke, die nur relevant ist wenn man ein Datacenter betreibt in dem sich viele Kunden Hardware-Ressourcen teilen?
 
@JumpingCat der Browser hat die Tür zum System geöffnet. ISt die Software aktuell ist das Risiko klein bzw. nur für ein kurzen Zeitraum über anreifbar. Sonst muss lokal/physisch zugegriffen werden.
Solange das Tor zum www aktuell und sicher ist, kann da wenig bis nichts passieren.
 
In diesem Fall kann man sich alle Rechte holen, mit lokalem Zugriff (der aber auch durch Software die man irgendwo lädt erfolgen kann). Also schon spezifischer als anderer Kram, einfach den Link der Schweizer lesen
 
@Salamimander der Teil gehört in den Startpost. Zittieren und ggf. erklären
 
Salamimander schrieb:
In diesem Fall kann man sich alle Rechte holen, mit lokalem Zugriff (der aber auch durch Software die man irgendwo lädt erfolgen kann). Also schon spezifischer als anderer Kram, einfach den Link der Schweizer lesen
Ja dann fang mal an alle Rechte zu holen. Scheint ja trivial zu sein.

@JumpingCat: Ist ein Fall bekannt, dass ein Privatanwender Opfer eines solchen Angriffs wurde?
 
@0x8100 Du hast damit bewiesen das lokaler Zugriff vorhanden sein muss. Ansonsten hätte es einen Online-Test gegeben.
 
@NameHere

Du kannst auch einfach den Artikel lesen und dir nicht alles vorkauen lassen. Falls du das alles nicht verstehst, ist das auch fein. Der Stick dient zum Testen. Die Software kann auch irgendwo embedded sein!
 
@Salamimander ich habe dir vorhin schon geschrieben, das du es in den Startpost packen sollst!
Und es sollte sehr deutlich und einfach erklärt werden wie genau das ganze erfolgt.

Der Artikel selbst ist dafür da, um dein Beitrag auf Richtigkeit zu überprüfen und mehr Details zu erhalten.
 
Du kannst da nett drum bitten aber das war’s auch schon. Bei deinem Ton hier werde ich das aber ganz sicher nicht tun.
 
  • Gefällt mir
Reaktionen: Mr. Poe
NameHere schrieb:
@0x8100 Du hast damit bewiesen das lokaler Zugriff vorhanden sein muss. Ansonsten hätte es einen Online-Test gegeben.
wenn ich was für dich bewiesen habe, dann freut mich das :) ich habe nur ein tool aufgezeigt, das auf eine anfälligkeit für rowhammer testet. wie das ausgenutzt werden kann, war für mich vollkommen out of scope.
 
  • Gefällt mir
Reaktionen: Mr. Poe und Salamimander
Zurück
Oben