پژوهش MIT: روش Interrupt Injection قادر به دور زدن تدابیر Spectre v2

پژوهشگران MIT CSAIL، دانیئل تراخیلو و منگجیا یان، تکنیکی با نام Interrupt Injection ارائه کردند که به فرایندهای بدون امتیاز روی لینوکس امکان می‌دهد یک وقفهٔ سخت‌افزاری را دقیقاً در بازهٔ زمانی بین پاک‌سازی شاخص شاخه (branch predictor) و استفادهٔ هسته از آن وارد کند و پس از اجرای مکانیزم محافظتی، شاخص را دوباره آلوده سازد.

عملکرد حمله و نتایج آزمایش

در آزمون روی ماشینی با پردازندهٔ AMD Zen 2 و هستهٔ لینوکس ۶٫۱۴ با تنظیمات پیش‌فرض کاهش تأثیر Spectre v2 فعال، اکسپلویت پژوهشگران توانست حافظهٔ دلخواه کرنل را با نرخ ۵٫۴۷ بایت در ثانیه و دقت ۹۱٫۹۷٪ نشت دهد؛ سرعت و دقتی که در پنج مورد از ده تلاش برای خواندن فایل /etc/shadow کافی بود. این حمله نیاز به امتیاز ندارد و اجرای محلی کد کافی است؛ بنابراین خطر برای سیستم‌های اشتراکی افزایش می‌یابد.

پنجرهٔ زمانی آسیب‌پذیری (TONTOU)

پژوهشگران این بازهٔ آسیب‌پذیری را TONTOU (مخفف Time-of-Neutralization to Time-of-Use) نامیده‌اند. شبیه منطق مسابقات TOCTOU در نرم‌افزار، تدابیر محافظتی شاخص شاخه قبل از ورود یا بازگشت کرنل پاک می‌شوند، اما اگر وقفه‌ای بین پاک‌سازی و استفاده رخ دهد، مسیر بازگشت از وقفه نیز بخشی از سطح حمله می‌شود. روی Zen 2 این پنجره تنها معادل دو دستورالعمل یا حدود ۶ بایت است. پژوهشگران با بیرون راندن آن بایت‌ها از کش‌های L1 و L2 از طریق یک هایپرترد هم‌زمان و انتخاب syscall از نوع write برای کنترل دو رجیستر، احتمال وقوع وقفه در آن پنجره را افزایش دادند.

واکنش تولیدکنندگان و پچ کرنل

تراخیلو و یان موضوع را در ۵ فوریه به AMD و Intel گزارش کردند. AMD اعلام کرد پچی برای هسته منتشر خواهد کرد و طبق اطلاعیهٔ MIT، این پچ از طریق به‌روزرسانی‌های معمول سیستم‌عامل منتشر شده است. کرنل لینوکس اصلاحی دریافت کرد: کامیتی با عنوان "x86/bugs: Make Safe-RET robust against interrupt injection" که در تاریخ ۲ ژوئن ثبت شد، ترتیب رجیسترها را طوری تغییر می‌دهد که اجرای دستور RET پس از بازگشت وقفه جلوگیری شود؛ یکی از راه‌حل‌های پیشنهادی پژوهش.

AMD سپس بولتینی با شناسهٔ AMD-SB-7061 و عنوان "Safe RET Interrupt Vulnerability" منتشر کرد و پردازنده‌های Zen 1 تا Zen 4 را در دامنهٔ تأثیر برشمرد. بولتین می‌گوید مهاجم محلی می‌تواند وقفه‌ای را در لحظه‌ای دقیق تزریق کند تا توالی Safe RET را مختل سازد و این امر "ممکن است" منجر به افشای اطلاعات شود. AMD این مسئله را مرتبط با پیاده‌سازی مکانیزم Safe RET در لینوکس می‌داند.

در مقابل، پژوهشگران به رسانه‌ها گفتند که اینتل کاهش را ضروری نمی‌داند. نکتهٔ عملی این است که بولتین AMD و اطلاعیهٔ MIT به یک شناسهٔ CVE یا ارجاع صریح به نسخهٔ خاص کرنل اشاره نکرده‌اند؛ بدون آن، مدیران سیستم باید تاریخچهٔ کرنل را مستقیماً بررسی کنند تا مطمئن شوند پچ دریافت شده است.

اهمیت عملی این حمله

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

عملکرد روی خانوادهٔ پردازنده‌های مختلف

خطاهای پیش‌بینی در کد کرنل در سه مورد از چهار ماشین آزمایشی ظاهر شدند: نرخ موفقیت ۰٫۷۵٪ روی Zen 2، ۰٫۲۲٪ روی Intel Arrow Lake و ۰٫۰۳۷٪ روی Cascade Lake Refresh. روی Zen 4 در آن آزمون خطا ثبت نشد و نشت انتها-تا-انتها روی اینتل نمایش داده نشد، هرچند پژوهشگران تأکید کرده‌اند که حضور یا نبود ابزار افشاگر در کرنل نقشی تعیین‌کننده دارد و موفقیت کمتر در برخی پردازنده‌ها به‌معنی عدم‌خطر نیست.

راهنمای عملی برای مدیران و کاربران

پیشنهادات برای کاهش ریسک:

• هستهٔ سیستم را به‌روز کنید تا کامیت «Make Safe-RET robust against interrupt injection» اعمال شده باشد؛ می‌توانید تاریخچهٔ کرنل را در git.kernel.org جست‌وجو کنید.
• وضعیت SRSO را در مسیر /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow بررسی و مستندات مربوطه را مرور کنید تا مشخص شود آیا سیستم‌تان تغییرات لازم را گزارش می‌دهد.
• در محیط‌های اشتراکی سیاست‌های محدودسازی اجرای کد محلی و ایزوله‌سازی را تقویت کنید و روندهای به‌روزرسانی کرنل را سریع پیگیری نمایید.
• بولتین‌های رسمی تولیدکنندگان، مانند AMD Product Security، و منابع تحقیقاتی مانند MIT CSAIL را برای دریافت پچ‌ها و توصیه‌های عملی دنبال کنید.

سوالات باز و چشم‌انداز آینده

پرسش‌های کلیدی همچنان پابرجا هستند: آیا توزیع‌ها و نسخه‌های مختلف هسته پیاده‌سازی Safe-RET را متفاوت انجام می‌دهند؟ آیا دیگر تولیدکنندگان مانند اینتل یا Arm اصلاحات نرم‌افزاری یا سخت‌افزاری ارائه خواهند کرد؟ پژوهش نشان می‌دهد که تزریق وقفه می‌تواند فرض «بدون اجرای کد بین پاک‌سازی و استفاده» را بشکند؛ بنابراین نیاز به بازنگری عمیق‌تر در طراحی و پیاده‌سازی تدابیر ضد-Spectre احساس می‌شود.

این رخداد بار دیگر تاکید می‌کند که محافظت در برابر اجرای حدسی (speculative execution) یک لایهٔ ثابت نیست؛ لازم است سیاست‌ها و پیاده‌سازی‌ها در سطوح سخت‌افزار، کرنل و فرآیندهای اجرایی هم‌زمان بازبینی شوند تا حملات زمان‌بندی‌شده مانند Interrupt Injection خنثی شوند.

منابع و مطالعهٔ بیشتر

برای مروری بر پس‌زمینهٔ Spectre به صفحهٔ Wikipedia دربارهٔ Spectre مراجعه کنید. اطلاع‌رسانی‌ها و بولتین‌های امنیتی رسمی تولیدکنندگان نیز منابع اصلی برای دنبال کردن پچ‌ها و راهنمایی‌های عملی هستند.