DDR5 Rentan terhadap Phoenix RowHammer: Analisis, Risiko, dan Mitigasi

Panduan Perangkat Keras » Komponen » RAM » DDR5 Rentan terhadap Phoenix RowHammer: Analisis, Risiko, dan Mitigasi

Komunitas keamanan dan perangkat keras sekali lagi melihat memori utama: serangan tipe RowHammer baru, yang dijuluki Phoenix (CVE-2025-6202), menunjukkan bahwa modul DDR5 SK Hynix tertentu tetap rentan meskipun telah dilengkapi perlindungan tingkat lanjut. Penelitian gabungan oleh ETH Zurich dan Google mengungkapkan, dengan pengujian yang dapat direproduksi, bahwa peningkatan hak istimewa ke root dimungkinkan pada komputer desktop dengan pengaturan default dalam hitungan menit. minutos.

Di luar judul utama, yang penting adalah para peneliti telah menjelaskan secara tepat mengapa pertahanan berbasis DRAM (TRR) gagal dan bagaimana mereka berhasil mengatasinya. Mereka telah mendokumentasikan pola hammering baru, pengaturan waktu penyegaran yang dapat mengoreksi sendiri, dan kondisi eksploitasi di dunia nyata yang memengaruhi lingkungan lokal dan multi-penyewaSemua ini disertai dengan artefak publik dan koordinasi yang bertanggung jawab dengan produsen dan penyedia cloud.

Apa itu RowHammer dan mengapa ia kembali populer?

RowHammer adalah kelemahan perangkat keras dalam DRAM di mana akses berulang ke suatu baris dapat menyebabkan bit flips di baris-baris yang berdekatan, sehingga menimbulkan kerusakan data. Sejak demonstrasi pertamanya pada tahun 2014, telah terlihat bahwa, seiring meningkatnya kepadatan sel untuk memperluas kapasitas, jumlah aktivasi yang diperlukan untuk menginduksi pembalikan bit pun meningkat. menurunkan, meningkatkan risiko.

Dampak praktisnya sudah diketahui: korupsi struktur sistem kritis, eskalasi hak istimewa, atau penolakan layanan. Penelitian sebelumnya telah menunjukkan bahwa kerentanan bergantung pada banyak variabel, termasuk suhu, tegangan, variasi produksi, pola data tersimpan, pola akses memori, dan kebijakan pengontrol.

Mitigasi seperti Error Correction Code (ECC) dan Target Row Refresh (TRR) telah diusulkan untuk mengatasi masalah ini. Namun, penelitian selanjutnya menunjukkan bahwa pertahanan ini dapat dielakkan dengan serangan yang lebih canggih: Lewati, SMASH, Half-Double, atau Blacksmith, dan masih banyak lagi. Efeknya bahkan terlihat di area yang tampaknya sangat berbeda, seperti fingerprinting perangkat melalui varian turunan.

Secara paralel, organisasi JEDEC baru-baru ini memperkenalkan mekanisme integritas yang disebut Per-Row Activation Counting (PRAC) untuk mendeteksi pola RowHammer dan mengekang lalu lintas agresif. Namun, menurut Google, sistem DDR5 yang diuji tidak menyertakan PRAC, sehingga membuka peluang bagi teknik eksploitasi baru. dalam produksi.

Phoenix (CVE-2025-6202): Siapa yang menemukannya dan apa fungsinya

Tim gabungan dari ETH Zürich (COMSEC) dan Google telah mengidentifikasi titik buta pada pertahanan TRR DDR5 terintegrasi SK Hynix. Phoenix mencapai peningkatan hak istimewa ujung ke ujung pertama pada PC konsumen dengan DDR5 standar, mencapai root dengan pengaturan default hanya dalam 109 detik dalam kasus yang paling menguntungkan, dan dengan waktu eksploitasi praktis rata-rata 5 menit dan 19 detik dalam demo tertentu.

Penelitian ini diuji pada sistem dengan CPU AMD Zen 4 dan modul SK Hynix DDR5, dengan tujuan untuk kemudian mereplikasinya pada memori dan prosesor lain. Hasilnya memengaruhi 15 modul yang diproduksi antara tahun 2021 dan 2024: semuanya menampilkan pembalikan bit di bawah salah satu dari dua pola baru yang dikembangkan oleh tim. Serangan tersebut telah diklasifikasikan sebagai CVE-2025-6202 dan diberi tingkat keparahan tinggi dalam CVSS v4 (7.1), dengan nilai dan vektor yang didokumentasikan dalam sumber seperti Mitre dan NVD.

Fakta yang relevan: ECC on-die tidak mencegah RowHammer di DDR5. Para penulis menunjukkan bahwa flip dapat terakumulasi seiring waktu, karena ECC on-chip melakukan koreksi selama penulisan atau dengan koreksi berkala (misalnya, setiap 24 jam). Hammering untuk periode yang lebih lama, dengan irama yang tepat, memungkinkan jalan pintas lapisan perlindungan itu.

Kemungkinan eksploitasi berkisar dari mengubah tabel halaman untuk mendapatkan akses baca/tulis yang sewenang-wenang, hingga mengekstraksi kunci RSA‑2048 dari mesin virtual yang berlokasi bersama (membobol otentikasi SSH) atau memanipulasi biner seperti sudo untuk meningkatkan hak istimewa lokal. Oleh karena itu, kita menghadapi skenario yang berdampak pada stasiun kerja dan infrastruktur bersama.

Bagaimana mereka mencapai bypass: TRR, periode pengambilan sampel, dan pola baru

Inti dari penemuan ini adalah rekayasa balik mitigasi TRR di DRAM. Melalui eksperimen berbasis FPGA menggunakan kesalahan retensi sebagai saluran samping, para peneliti mengamati bahwa sistem pengambilan sampel TRR mengulangi periodenya setiap 128 interval tREFI, rentang 8 kali lebih lebar daripada yang direncanakan oleh pola RowHammer klasik.

Dengan “memperbesar”, penelitian menunjukkan bahwa, dalam 64 interval terakhir dari siklus tersebut, terdapat substruktur berulang dari empat sub-interval di mana dua yang pertama diambil sampelnya sedikit atau hampir tidak ada. Asimetri ini meninggalkan jendela peluang: jika palu sejajar dengan zona “sampel ringan” ini, pertahanan tidak mendeteksi aktivitas agresif pada waktunya.

Dengan petunjuk itu, tim tersebut menyimpulkan dua pola berdurasi panjang. Pola pertama hanya mencakup 128 tREFI; hindari palu di awal dan pusatkan aktivitas pada pita-pita pengambilan sampel rendah, ulangi bagian kedua sebanyak 16 kali untuk mengumpulkan 32 interval palu efektif per repetisi. Bagian kedua mencakup pola yang jauh lebih panjang 2608 tREFI, ditujukan untuk perangkat lain dengan perbedaan internal.

Waktu adalah hal yang penting: hanya 2 dari 128 Offset penyegaran rentan, memberikan probabilitas hit awal sebesar 1,56%. Untuk meningkatkan peluang mereka, mereka menjalankan urutan offset yang sama secara paralel di masing-masing dari empat bank, meningkatkan probabilitas mencapai offset yang benar sebesar 16 hingga kira-kira 25%.

Sinkronisasi yang dapat mengoreksi diri sendiri: sebuah lompatan besar ke depan dari upaya sebelumnya

Tantangan utama adalah menjaga keselarasan dengan minuman ringan selama ribuan interval, karena pola Phoenix berukuran 1 hingga 2 kali lipat lebih besar daripada pola pada umumnya. Para penulis menemukan bahwa rutin sinkronisasi Zenhammer, bahkan dalam varian multi-utas, tidak mempertahankan stabilitas cukup lama untuk memicu flip secara andal.

Solusinya adalah teknik sinkronisasi yang mengoreksi diri sendiri yang memanfaatkan periodisitas penyegaran: tidak perlu mendeteksi setiap perintah; melainkan, mendeteksi ketidakselarasan dan menyelaraskan kembali eksekusi pola agar tetap berjalan, bahkan ketika penyegaran yang tepat waktu terlewat. Pendekatan ini memungkinkan untuk mempertahankan koherensi di ribuan tREFI.

Untuk menggambarkan peningkatannya, para peneliti menunjukkan bahwa berkat sinkronisasi yang kuat ini mereka dapat menjaga pola mereka dalam waktu yang tepat dengan siklus internal TRR, sesuatu yang tidak dapat dicapai oleh metode sebelumnya tanpa jatuh ke dalam celah setelah beberapa ratus interval.

Dalam praktiknya, stabilitas inilah yang memungkinkan penskalaan menyeluruh pada suatu mesin. Desktop dengan DDR5, yang berpuncak pada hak akses root dengan parameter default dalam waktu seagresif 109 detik dalam demonstrasi mereka.

Hasil eksperimen: 15 DIMM yang rentan dan flip yang dapat dieksploitasi

Tim mengevaluasi 15 modul DDR5 dari SK Hynix diproduksi antara akhir 2021 dan akhir 2024. Semuanya menunjukkan bit flips dengan salah satu dari dua pola tersebut. Pola tREFI pendek 128 menghasilkan, rata-rata, 2,62 × lebih efisien daripada yang panjang, menghasilkan urutan ribuan flips per DIMM: makalah tersebut mengutip rata-rata perkiraan 4989 kali membalik dalam pengujian mereka.

Pembalikan ini menjadi primitif nyata dalam tiga skenario yang sudah diketahui: (i) korupsi PTE untuk membaca/menulis memori sembarangan (semua DIMM yang rentan); (ii) ekstraksi kunci RSA‑2048 dari VM yang ditempatkan bersama untuk merusak SSH (pada 73% (DIMM yang rentan); dan (iii) modifikasi biner sudo untuk meningkatkan hak istimewa lokal (dalam 33% DIMM yang rentan).

Selain itu, penulis mereplikasi untuk pertama kalinya dalam DDR5 peningkatan hak istimewa pekerjaan Rubicon, menunjukkan waktu eksploitasi rata-rata 5:19 dalam kondisi pengujian yang terkendali, memperkuat kelayakan praktis serangan di luar laboratorium.

Pengujian ini didukung pada sistem dengan CPU AMD Zen 4 dan modul SK Hynix. Tim berencana untuk memperluas pengujian ke sistem lain. produsen dan arsitektur untuk memahami cakupan penuh; namun, kombinasi saat ini sudah mewakili lingkungan desktop DDR5 modern.

Sebagai data risiko agregat, berbagai metrik menempatkan Phoenix dalam tingkat keparahan yang relevan: CVSS v4 7.1 (Tinggi) dengan vektor terdokumentasi; CVSS v3 5.5 (Sedang) dengan vektor AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N; dan CVSS v2 2.1 (Rendah) dengan vektor AV:L/AC:L/Au:N/C:N/I:P/A:N. EPSS terkait diperkirakan sebesar 0.00014, yang mencerminkan kemungkinan eksploitasi yang diamati dalam ekosistem, meskipun angka ini harus ditafsirkan bersama dengan dampak teknis yang terbukti.

Mitigasi dan biaya pertahanan saat ini

Sebagai tindakan kejutan, para peneliti merekomendasikan tiga kali lipat refresh rate (3×), yang pada sistem mereka menghentikan Phoenix flips. Karena tREFI ada di sekitar 1,3 μs, penyesuaian ini menyiratkan lebih banyak operasi penyegaran dan, oleh karena itu, biaya kinerja yang terukur: dalam SPEC CPU2017 mereka melaporkan hingga 8,4% kelebihan beban.

Mereka juga menunjukkan bahwa pemasok dan OEM memiliki pengaruh langsung: Pembaruan BIOS/firmware untuk menyesuaikan kebijakan memori atau menyegarkan parameter. Faktanya, di masa embargo, AMD mengumumkan ketersediaan pembaruan BIOS untuk mesin klien, meskipun penulis tidak dapat memverifikasi secara independen sejauh mana pembaruan tersebut secara khusus mengurangi Phoenix.

Penting: ECC on-die bukanlah "perisai ajaib". Menurut makalah tersebut, koreksi tertunda memungkinkan flip terakumulasi jika penyerang melakukan hammer dengan pola yang lolos filter TRR. Oleh karena itu, ODECC tidak dengan sendirinya mencegah serangan berlanjut di DDR5 dalam kondisi yang dijelaskan.

Dalam jangka menengah, sektor ini membutuhkan mitigasi yang “prinsipal”, bukan respons ad-hoc terhadap setiap pola baru. JEDEC telah mendefinisikan PRAC, tetapi para penulis dan Google menunjukkan bahwa Sistem DDR5 Pengujian tidak menyertakannya, sehingga membuka peluang untuk penghindaran. Penerapan mekanisme penghitungan baris dan kebijakan penyegaran adaptif yang lebih luas dapat meningkatkan standar secara signifikan.

Konteks: Serangan lain dan peran server ECC

RowHammer telah mengumpulkan berbagai varian, masing-masing memberikan tekanan pada sisi pertahanan yang berbeda. Selain TRRespass, SMASH, Half-Double, dan Blacksmith, penelitian terbaru telah menunjukkan OneFlip (balik sedikit untuk mengubah bobot model DNN dan menyebabkan perilaku yang tidak diinginkan) dan ECC.gagal (serangan ujung-ke-ujung pertama yang berhasil terhadap mesin server DDR4 dengan memori ECC, yang menyebabkan pembalikan pada lokasi tertentu yang menghindari deteksi/koreksi).

Secara teori, server memiliki perlindungan ekstra terhadap kerusakan memori (seperti ECC untuk sinar kosmik atau RowHammer), tetapi ECC.fail menunjukkan bahwa, dengan stimulus yang tepat, mereka juga dapat menyerahkanPhoenix bergabung dalam daftar itu di lini depan DDR5 desktop, membuktikan bahwa keseimbangan antara kepadatan, kinerja, dan ketahanan adalah garis tipis.

Bahkan produsen dan ekosistem yang sudah mapan pun telah terpengaruh oleh penelitian tersebut (misalnya, Nvidia atau platform DDR4), dan ini bukan suatu kebetulan: ketika transistor dan sel semakin dekat, interferensi listrik dan saluran samping mengalami celah yang tidak ada sebelumnya.

Pembelajarannya jelas: mitigasi harus berkembang seiring dengan fisika perangkat keras, mengintegrasikan telemetri dan respons dinamis yang lepas dari asumsi pengambilan sampel statis, tepatnya titik lemah yang dieksploitasi Phoenix dalam evaluasi DDR5.

Pengungkapan yang bertanggung jawab, kronologi dan sumber daya

ETH Zürich memulai proses pengungkapan yang bertanggung jawab melalui NCSC Swiss pada 6 Juni 2025, memberi tahu SK Hynix, produsen CPU, dan penyedia cloud utama. Masalah ini tetap diembargo hingga 15 September 2025. Sesaat sebelumnya, pada 12 September, AMD melaporkan BIOS untuk komputer klien, tanpa verifikasi independen oleh penulis.

Karya lengkap akan dipresentasikan di Simposium IEEE tentang Keamanan dan Privasi 2026Makalah dan artefak (termasuk PoC dan alat pengujian) tersedia untuk umum: Anda dapat merujuk ke PDF dan repositori untuk mereproduksi pengujian dan mengevaluasi modul Anda di laboratorium yang terkendali.

Tautan Bermanfaat: kertas dalam format PDF y Repositori Phoenix di GitHubGoogle juga menerbitkan sebuah entri di Blog Keamanan membahas cakupan dan alat pengujian untuk DDR5.

Kartu kerentanan menunjukkan sebagai sumber Mitra y NDV, diterbitkan dan diperbarui pada 15 September 2025, dengan nama Phoenix. Tag CVE-2025-6202 dan vektornya memungkinkan tim risiko untuk memprioritaskan dan memetakan keputusan mitigasi menggunakan kriteria yang konsisten.

Catatan produsen dan pertimbangan hukum

AMD telah menerbitkan pernyataan yang menekankan bahwa informasi teknis mungkin berisi ketidakakuratan, tidak memberikan jaminan, baik tersurat maupun tersirat, dan tidak bertanggung jawab atas penggunaan perangkat keras atau perangkat lunak yang dijelaskan. Perlu diketahui juga bahwa merek AMD, EPYC, dan Ryzen kepemilikan perusahaan, dan akronim CVE serta logonya adalah milik The MITRE Corporation.

Pemberitahuan yang sama menyatakan bahwa konten pihak ketiga yang tertaut disediakan “apa adanya” (DENGAN ADANYA) dan penggunaannya merupakan risiko pembaca sendiri. Jenis penafian ini umum dalam dokumentasi teknis dan tidak memengaruhi validitas temuan akademisi, tetapi perlu diingat dalam penerapan yang produktif dan komunikasi perusahaan.

Apa yang harus dilakukan oleh pengguna, administrator, dan penyedia

Jika Anda menjalankan mesin SK Hynix DDR5, langkah pertama adalah inventaris modul dan tinjau versi BIOS/firmware yang tersedia untuk platform Anda. Banyak OEM mungkin merilis penyempurnaan yang meningkatkan ambang batas keamanan sementara mitigasi yang lebih mendalam diterapkan.

Kedua, uji di lab tertutup (tidak pernah dalam produksi) untuk kerentanan terhadap artefak Phoenix publik, terutama jika Anda mengoperasikan lingkungan multi-penyewa atau beban kerja sensitif (misalnya, claves memori kriptografi). Alat ETH/Google mencakup utilitas uji yang dirancang untuk DDR5, dengan rekomendasi eksplisit untuk penggunaan yang bertanggung jawab.

Jika tes Anda menunjukkan flips, pertimbangkan untuk mengaktifkan 3× soda Pada sistem yang paling kritis, dengan asumsi biaya kinerja. Pada beban yang diizinkan oleh SLA, 8,4% yang diukur dalam SPEC mungkin merupakan harga yang wajar dibandingkan dengan kemungkinan eskalasi lokal atau kebocoran rahasia antar penyewa.

Di cloud pribadi atau lingkungan dengan VM yang ditempatkan bersama, batasi afinitas dan isolasi, serta meminimalkan paparan rahasia bernilai tinggi dalam memori ketika diduga terdapat koresidensi yang tidak tepercaya. Hal ini disertai dengan aturan pemantauan dan respons untuk pola akses memori yang anomali.

Terakhir, nantikan masa depan pembaruan standar (misalnya, PRAC) dan upaya produsen untuk mengintegrasikan perlindungan berdasarkan penghitungan baris dan kebijakan penyegaran adaptif. Phoenix menunjukkan bahwa, tanpa lompatan kualitatif ini, industri akan terus bermain kucing-kucingan dengan setiap inovasi baru. variasi dari pola.

Meskipun vektor utamanya bersifat lokal (AV:L di CVSS v3), dampaknya terhadap integritas tinggi dan jendela eksploitasi pendek, dengan bukti eskalasi ke root, pencurian kunci RSA‑2048 dan manipulasi dari biner kritis. Menggabungkan penguatan langsung, pengujian terkontrol, dan pemantauan patch, saat ini, merupakan strategi yang paling masuk akal.

Kasus Phoenix menyoroti betapa kecilnya ketidakcocokan dalam strategi pengambilan sampel TRR dapat merusak pertahanan yang secara teoritis kuat. Dengan sinkronisasi yang dapat mengoreksi sendiri, pola tREFI 128 dan 2608, paralelisasi bank, dan penyelarasan penyegaran yang cermat (hanya 2 dari 128 offset yang valid, meningkatkan probabilitas menjadi 25% ketika mengeksploitasi empat bank sekaligus), serangan ini menegaskan bahwa DDR5 bukanlah tempat berlindung yang aman secara default terhadap RowHammer. Dengan kekuatan hasil eksperimen, kemungkinan eksploitasi menyeluruh dalam hitungan menit, dan biaya mitigasi sementara yang terjangkau (penyegaran 3x), pesan bagi tim teknis jelas: tindakan sekarang perlu diambil, tanpa menunggu solusi sempurna, sambil mendorong industri untuk mengintegrasikan pertahanan awal seperti PRAC dan kebijakan penyegaran baru yang lebih cerdas.