پژوهشگران دانشگاه و صنعت یک گونهٔ جدید از حملات Rowhammer را طراحی کردهاند که میتواند مکانیسمهای محافظتی جدید روی ماژولهای حافظهٔ DDR5 شرکت SK Hynix را ناکار کند. این روش جدید که پژوهشگران آن را «Phoenix» نامیدهاند، نشان میدهد حتی نسل جدید حافظهها نیز نسبت به حملات تغییر بیت (bit-flip) آسیبپذیر هستند.
Rowhammer چیست و چرا خطرناک است؟
حملهٔ Rowhammer با دسترسی تکراری و سریع به ردیفهای خاصی از سلولهای حافظه، اختلال الکتریکی ایجاد میکند که در نتیجه بیتهای مجاور میتوانند از ۰ به ۱ یا برعکس تغییر کنند (bit flipping). چنین تغییراتی ممکن است منجر به خرابشدن داده، افزایش سطح دسترسی مهاجم، اجرای کد مخرب یا افشای دادههای حساس شود.
یکی از مکانیزمهای دفاعی مقابل Rowhammer به نام Target Row Refresh (TRR) است که با تشخیص دسترسیهای مکرر به یک ردیف، یک فرکانس تازهسازی (refresh) اضافی صادر میکند تا از بیتفلیپ جلوگیری شود.
چه اتفاقی افتاده؟ معرفی Phoenix
تیمی از محققان از گروه امنیت کامپیوتر (COMSEC) در دانشگاه ETH زوریخ و محققانی از گوگل، حملهای جدید روی DDR5 را طراحی کردند و آن را Phoenix خواندند. آنها پس از مهندسی معکوس تدابیر پیچیدهٔ حفاظتی پیادهسازیشده توسط Hynix، نقاط ضعف در نمونهبرداری (sampling) برخی refresh intervals را کشف کردند که قابل بهرهبرداری است.
محققان همچنین روشی توسعه دادند تا Phoenix بتواند با هزاران عملیات تازهسازی همگام (synchronize) شود و اگر یکی از آنها از دست رفت خودبهخود اصلاح (self-correct) کند — قابلیتی که امکان پیگیری و هماهنگی با سیکلهای حافظه را فراهم میکند.
برای فرار از محافظت TRR، الگوهای hammering در Phoenix فواصل تازهسازی ۱۲۸ و ۲۶۰۸ را پوشش میدهند و تنها در اسلاتهای فعالسازی مشخص و «در لحظات دقیق» عملیات را اجرا میکنند. با استفاده از این مدل، پژوهشگران توانستند بیتها را روی هر ۱۵ ماژول DDR5 موجود در مجموعه آزمایش تغییر دهند و نخستین اکسپلویت Rowhammer برای افزایش دسترسی (privilege escalation) را بسازند.
در آزمایشها، آنها توانستند در کمتر از دو دقیقه در یک سیستم معمولی DDR5 با تنظیمات پیشفرض، به یک شل با دسترسی root دست یابند.
نتایج تجربی: اهداف عملیِ Phoenix
محققان کاربردهای عملی Phoenix را نیز بررسی کردند:
با هدفگیری صفحات جدول نگاشت حافظه (PTEs)، آنها توانستند یک primitive خواندن/نوشتن دلخواه حافظه بسازند؛ همهٔ محصولات آزمایششده در برابر این روش آسیبپذیر بودند.
در یک سناریوی دیگر، وقتی RSA-2048 یک ماشین مجازی هممیزبان (co-located VM) نشانهگیری شد تا احراز هویت SSH شکسته شود، مشخص شد ۷۳٪ از DIMMها در معرض بودند.
در آزمون سوم، پژوهشگران توانستند باینری
sudoرا تغییر دهند تا روی ۳۳٪ از ماژولها حق دسترسی محلی خود را به سطح root افزایش دهند.
در جدول نتایج مشخص شد که الگوی کوتاهتر (۱۲۸ refresh interval) مؤثرتر است و بهطور میانگین بیتفلیپهای بیشتری تولید میکند. مجموعاً همهٔ ماژولهای DDR5 مورد آزمایش بهنوعی در برابر یکی از الگوهای Phoenix آسیبپذیر بودند.
وضعیت CVE و دامنهٔ اثر
حملهٔ Phoenix با شناسهٔ امنیتی CVE-2025-6202 ردیابی شده و امتیاز شدت بالایی دریافت کرده است. طبق گزارش، این حمله تمام ماژولهای DIMM تولیدشده بین ژانویهٔ ۲۰۲۱ تا دسامبر ۲۰۲۴ را تحت تأثیر قرار میدهد.
راههای کاهش ریسک و محدودیتها
از آنجا که Rowhammer یک مشکل سراسری در صنعت حافظه است و برای ماژولهای موجود راهحل سختافزاریِ سادهای ندارد، پژوهشگران راهکار موقتی زیر را پیشنهاد کردهاند: سهبرابر کردن فاصلهٔ تازهسازی DRAM (tREFI). این کار میتواند حملهٔ Phoenix را متوقف کند، اما با هزینهٔ قابلتوجه: افزایش tREFI میتواند منجر به خطاها، خرابشدن داده یا ناپایداری سیستم شود و بههمخوردن عملکرد حافظه را بهدنبال داشته باشد.
مقالهٔ فنی با عنوان «Phoenix: Rowhammer Attacks on DDR5 with Self-Correcting Synchronization» منتشر شده و در IEEE Symposium on Security and Privacy سال آینده ارائه خواهد شد. پژوهشگران همچنین مخزنِ منابعی شامل تجربیات مبتنی بر FPGA برای مهندسی معکوس پیادهسازیهای TRR و کد PoC (اثبات مفهوم) را منتشر کردهاند تا امکان بازتولید آزمایشها فراهم شود.
جمعبندی و توصیهها
ظهور Phoenix بار دیگر نشان میدهد که حتی حافظههای نسل جدید DDR5 نیز میتوانند مورد سوءاستفاده قرار گیرند و دفاعهای سختافزاری پیچیده همیشه قطعی نیستند. پیشنهادهای عملی برای سازمانها و مدیران سیستم:
در هماهنگی با سازندگان مادربورد / OEM و تولیدکنندهٔ ماژولهای حافظه، دنبال بهروزرسانیهای فریمورم یا اصلاحات سختافزاری باشید.
در سیستمهای حساس، ارزیابی ریسک انجام دهید و اگر امکانپذیر است پارامترهای refresh را بعد از آزمون دقیق تغییر دهید.
سطح مجوزهای بحرانی را محدود و مانیتورینگ غیرعادی حافظه را فعال کنید.
برای سرویسهای ابری و محیطهای میزبان چند-مشتری (multi-tenant)، اقدامات ایزولهسازی بیشتری پیاده کنید تا آسیبپذیریهای هممیزبانی کاهش یابد.
