خلاصه‌ای از کشف

کریستوفر دومس با انتشار پروژهٔ متن‌باز skitter-creek-bath-salts نشان داد که با دستکاری رجیسترهای ترجمهٔ کنترلر حافظه می‌توان نگاشت فیزیکی→DRAM را در سطح سخت‌افزار به‌صورت پویا تغییر داد و بدین‌وسیله از مکانیسم‌های حفاظتی بالادستی عبور کرد. این روش، امکان دسترسی به نواحی حافظهٔ محافظت‌شده را فراهم می‌آورد، بدون آنکه کنترل‌های امنیتی بالاتر متوجه شوند.

مکانیسم فنی: چگونه دستکاری رجیستر کنترلر DRAM آدرس‌ها را جابه‌جا می‌کند

کنترلرهای حافظه رجیسترهایی دارند که نحوهٔ محاسبهٔ بانک، ردیف و ستون در DRAM را تعیین می‌کنند. با تغییرِ بیت‌های پیکربندی مانند BankSwizzleMode، کنترلر آدرس‌های فیزیکی را «swizzle» می‌کند تا مختصات DRAM به‌صورت متفاوتی محاسبه شوند. از آنجا که بسیاری از فیلترهای امنیتی بالادستی آدرس‌ها را قبل از ترجمهٔ نهایی اعتبارسنجی می‌کنند، این بازچینش می‌تواند منجر به دسترسی‌های عادی به سلول‌های محافظت‌شده شود، بدون آنکه خطا یا تله‌ای رخ دهد.

برای مرور مفاهیم پایه می‌توان به معرفی DRAM و حالت مدیریت سیستم (DRAM، SMM) مراجعه کرد.

خط لولهٔ بهره‌برداری

زنجیرهٔ بهره‌برداری ارائه‌شده شامل چند مرحلهٔ نرم‌افزاری و تحلیلی است تا نگاشت واقعی بدون ناپایداری سیستم‌عامل کشف و بهره‌برداری شود:

  • ماژول هستهٔ لینوکس برای آفلاین کردن هسته‌های غیر بوت، پاک‌سازی کش‌ها، گرم‌کردن/قفل‌کردن TLBها و غیرفعال‌سازی وقفه‌ها تا ثبات نگاشت حفظ شود.
  • اسکریپت‌های پروبینگ خودکار با هیوریستیکِ «گردآور کوپن» (coupon-collector) و خوانش‌های هدفمند فضای آدرس برای شناسایی بیت‌های تغییرپذیر.
  • مدلسازی نگاشت بازچینش آدرس با حساب در میدان گالوا (Galois Field) و استفاده از حل‌کننده‌های SMT برای استخراج نگاشت بیت‌به‌بیت (ابزار مرجع: Z3).
  • پس از استخراج نگاشت، انجام خواندن/نوشتن‌های هدفمند علیه نواحی پیش‌تر غیرقابل‌دسترس.

اهداف عملیاتی

بهره‌برداری توانسته به نواحی حساسی مانند RAM مود مدیریت سیستم (SMM)، جداول فرم‌ویر پردازندهٔ امنیتی پلتفرم (PSP)، نواحی ذخیرهٔ حالت خواب پردازنده (مثل CC6) و بافرهای پچ میکروکد دسترسی پیدا کند.

پیامدهای معماری و تهدیدات عملی

این کشف نشان می‌دهد کنترل‌های امنیتی اعمال‌شده در لایهٔ هسته و fabric سیستم اگر کنترلر حافظه قادر به بازچینش آدرس‌ها باشد، بی‌اثر خواهند شد. این تهدید به‌ویژه برای محیط‌های ابری bare-metal و سامانه‌های confidential computing جدی است، زیرا تکیه صرف بر امن بودن هسته دیگر کافی نیست.

نکتهٔ کلیدی این است که دسترسی به این رجیسترها در عمل نیازمند امتیاز Ring 0 است؛ همچنین رجیسترهای هدف‌گرفته عمدتاً در نسل‌های قبلی پردازنده‌های AMD (خانوادهٔ 14h، 15h و 16h) گزارش شده‌اند.

محدودیت‌ها و دامنهٔ اثر

  • برای اجرای بهره‌برداری لازم است کد در سطح Ring 0 اجرا شود؛ بنابراین بدافزارهای کاربران عادی بدون ارتقاء امتیاز، قادر به بهره‌برداری مستقیم نیستند.
  • بخشی از خطر متوجه سیستم‌هایی است که کنترلرهای قدیمی یا رجیسترهای پیکربندی‌نشده دارند؛ معماری‌های جدید که ترجمه‌ها را در بوت قفل می‌کنند یا دسترسی به رجیسترها را محدود می‌سازند، کمتر در معرض این حمله قرار دارند.

راهکارها و توصیه‌های مهندسی

تدابیر موثر در سطح سخت‌افزار و پلتفرم شامل موارد زیر است:

  • قفل‌سازی سخت‌افزاری رجیسترهای ترجمهٔ کنترلر حافظه در طول فرآیند بوت و جلوگیری از تغییر آن‌ها در زمان اجرا.
  • انتقال مدیریت پیکربندی‌های حساس به سطوحی که بالاتر از امتیازات CPU قرار دارند، برای نمونه پردازندهٔ امنیتی پلتفرم یا فریمور اولیهٔ بوت.
  • بازبینی و ممیزی firmware/BIOS توسط تولیدکنندگان و اپراتورهای دیتاسنتر برای شناسایی رجیسترهای قابل‌تغییر در runtime و اصلاح پیکربندی‌های ناامن.
  • گنجاندن بررسی‌های تشخیصی برای کشف بازچینش‌های غیرمنتظرهٔ آدرس در فرآیندهای تست سخت‌افزار و فریمور.

واکنش جامعه و گام‌های بعدی

جوامع مهندسی معکوس و امنیت سخت‌افزار در شبکه‌ها و پادکست‌های تخصصی واکنش نشان داده و مباحث فنی گسترده‌ای دربارهٔ پیامدهای معماری و راهکارهای مقابله مطرح شده است. اپراتورهای ابری، تولیدکنندگان سخت‌افزار و تیم‌های امنیتی باید موجودی سخت‌افزاری خود را بررسی کنند و ارزیابی کنند که آیا کنترلرهایشان امکان جابه‌جایی آدرس در runtime را دارند یا خیر.

نتیجه‌گیری و انتظار پیش رو

این کشف فشار بیشتری بر سازندگان سخت‌افزار وارد می‌کند تا پیکربندی‌های حساس را از دسترسی‌های سطح هسته جدا کنند. انتظار می‌رود پژوهش‌های پیرو ابزارهای تشخیصی و پچ‌های فریموری برای کاهش ریسک ارائه دهند؛ هم‌زمان اپراتورها باید فرض وقوع هسته‌های خصمانه را وارد مدل تهدیدات خود کنند و سازوکارهای حفاظتی فراتر از اعتماد صرف به Ring 0 پیاده‌سازی نمایند.