محققای دانشگاه Tsinghua و مریلند و BUPT یه حمله کانال جانبی جدیدی رو معرفی کردن، که CPUهای اینتل رو تحت تاثیر قرار میده.
این حمله جدید به جای استفاده از سیستم cache که اغلب در این حملات مورد استفاده قرار میگیره، از نقص در transient execution استفاده میکنه و میتونه داده های حساس رو از فضای حافظه کاربر، از طریق آنالیز زمان ، استخراج کنه. اسم این تکنیک Transient Execution Timing هستش.
نکته ای که هست اینه که این تکنیک بعنوان یه کانال جانبی برای Meltdown هستش که یه آسیب پذیری مهم بود که در سال 2018 کشف شد و خیلی از ریزپردازنده های مبتنی بر X86 تحت تاثیر قرار داد.
Meltdown از یه ویژگی بهینه سازی عملکرد بنام speculative execution سوء استفاده می کرد و مهاجم میتونست با این آسیب پذیری ، مکانیسم جداسازی حافظه رو دور بزنه و به داده های حساس ذخیره شده در حافظه کرنل مثله پسوردها، کلیدهای رمزنگاری و … دسترسی داشته باشه.
Meltdown از طریق اصلاحیه های نرم افزاری، بروزرسانی microcode و طراحی مجدد سخت افزار کاهش یافت اما بطور 100 درصد رفع نشد. تکنیکهای جدید میتونه این آسیب پذیری رو در سیستم هایی که بطور کامل از لحاظ نرم افزاری و سخت افزاری اصلاح شدن هم تحت تاثیر بزاره.
حمله جدید از یه نقص روی رجیستر EFLAGS در transient execution استفاده میکنه که روی زمان بندی دستور JCC (jump on condition code) تاثیر میزاره.
رجیستر EFLAGS یه رجیستر CPU هستش که فلگ های مختلفی رو نسبت به وضعیت پردازه نگه میداره. JCC هم یه دستور پرش شرطی هستش که نسبت به فلگ های رجیستر EFLAGS عمل پرش رو انجام میده.
حمله دو مرحله رو داره:
- در مرحله اول transient execution فعال میشه و داده های حساس از طریق رجیستر EFLAGS انکد میشه
- در مرحله دوم زمان اجرای دستور JCC برای دیکد کردن داده ها محاسبه میشه.
نتایج تحقیق نشون میده که این روش تونسته داده های حساس رو ، روی پردازنده های Intel i7-6700 و Intel i7-7700 بصورت 100 درصدی لیک کنه و روی CPUهای جدید مثله Intel i9-10980XE عملکرد موفقیت آمیزی داشته. تست هم روی Ubuntu 22.04 jammy با Linux kernel version 5.15.0 انجام شده.
محققا گفتن که این روش به اندازه حملات کانال جانبی مبتنی بر کش، مورد اعتماد نیست و روی پردازنده های جدید باید هزاران بار تکرار بشه. علتش هم اینه که تاثیر رجیستر EFLAGS روی زمان اجرای دستور JCC به اندازه حالت cache پایدار نیستش.
محققا اعلام کردن که علت اصلی حمله مبهم هستش و یسری اقدامات کاهشی هم براش معرفی کردن:
- تغییر در اجرای دستور JCC به منظور جلوگیری از حمله
- بازنویسی EFLAGS بعد از transient execution برای کاهش تاثیر اون روی JCC