چگونه یک باگ اخیراً کشف شده در پردازنده های اینتل، ارائه دهندگان سرویس های ابری را تهدید می کند.
در ۱۴ نوامبر، گوگل بولتنی منتشر کرد که در آن یک آسیبپذیری جدی در تعدادی از پردازندههای اینتل گزارش شد. (از نسل Ice Lake که در سال ۲۰۱۹ منتشر شد) به طور بالقوه این آسیبپذیری میتواند منجر به انکار سرویس، تشدید امتیازات یا افشای اطلاعات حساس شود. در زمان نگارش این مقاله، بهروزرسانیهای میکروکد برای رسیدگی به این مشکل برای پردازندههای نسل دوازدهم و سیزدهم اینتل (به ترتیب Alder Lake و Raptor Lake) منتشر شده است. وصله های پردازنده های نسل دهم و یازدهم (Ice Lake و Tiger Lake) در حال انجام است. لیست کامل پردازنده های آسیب دیده در وب سایت اینتل در قالب یک صفحه گسترده گسترده موجود است.
به گفته نمایندگان اینتل، مهندسان این شرکت از رفتار غیرعادی پردازنده ها آگاه بودند، اما این مشکل غیر بحرانی تلقی شد و برنامه ریزی برای حل آن به نیمه اول سال 2024 موکول شد. با این حال، زمانی که محققان گوگل متوجه شدند مشکل به طور مستقل در واقع، تمام جزئیات مربوط به این آسیبپذیری در واقع از متخصصان Google، بهویژه از این مقاله توسط Tavis Ormandy آمده است.
فازی شدن پردازنده
Tavis Ormandy آسیب پذیری های عمده زیادی را در برنامه ها و دستگاه های مختلف کشف کرده است. اخیراً در مورد تحقیقات قبلی او نوشتیم که آسیبپذیری Zenbleed را در پردازندههای AMD پیدا کرده بود. در آن مناسبت، تاویس در مورد اتخاذ fuzzing برای یافتن آسیبپذیریهای سختافزاری صحبت کرد.
Fuzzing یک روش آزمایشی است که شامل وارد کردن اطلاعات تصادفی به ورودی سیستم اطلاعاتی مورد آزمایش است. معمولاً از آن برای خودکارسازی جستجوی آسیبپذیریهای نرمافزار استفاده میشود: یک ابزار fuzzing ویژه برای تعامل با برنامه و نظارت بر وضعیت آن ایجاد میشود. پس از آن، ده ها یا صدها هزار آزمایش برای شناسایی رفتار غیرعادی در کد آزمایش شده انجام می شود.
وقتی نوبت به آزمایش پردازنده ها می رسد، همه چیز کمی پیچیده تر است. ما باید برنامههای تصادفی را تولید کنیم که بدون نقص کار کنند و آنها را روی پردازنده اجرا کنیم. چگونه می توانیم رفتار نرمال پردازنده را از رفتار غیرعادی در چنین حالتی متمایز کنیم؟ از این گذشته، هر خطایی در حین اجرای نرم افزار منجر به خرابی نمی شود. Ormandy تکنیکی را پیشنهاد کرد که در آن کد “تصادفی” یکسانی به طور همزمان بر روی پردازنده های مختلف اجرا می شود. از لحاظ نظری، خروجی یک برنامه یکسان نیز باید یکسان باشد. اگر اینطور نیست، می تواند نشان دهنده یک مشکل باشد. این رویکرد بود که آسیب پذیری را در پردازنده های اینتل آشکار کرد.
کد بی فایده اما خطرناک
برای درک نحوه عملکرد آسیبپذیری Reptar، باید به پایینترین سطح برنامهنویسی برویم – کد ماشینی که پردازندهها مستقیماً اجرا میکنند. از زبان اسمبلی برای نمایش چنین دستورالعمل های اساسی به روشی راحت تر استفاده می شود. یک قطعه کد زبان اسمبلی چیزی شبیه به این است:
آخرین خط دارای دستورالعمل movsb است که به پردازنده می گوید داده ها را از یک ناحیه حافظه به منطقه دیگر منتقل کند. قبل از آن اصلاح کننده rep وجود دارد که نشان می دهد دستور movsb باید چندین بار پشت سر هم اجرا شود. چنین پیشوندهایی برای همه دستورالعمل ها مرتبط نیستند. پردازنده های اینتل می دانند که چگونه از پیشوندهای بی معنی عبور کنند.
بیایید پیشوند دیگری به نام rex.rxb اضافه کنیم. این در کنار معماری x86-64 برای کنترل هشت رجیستر پردازنده اضافی معرفی شد. اگرچه دقیقاً چه کاری انجام می دهد چندان مهم نیست – تنها چیزی که باید بدانیم این است که این پیشوند هنگام استفاده با دستور movsb معنی ندارد:
در واقع، این پیشوند رفتار پردازندههای اینتل را تغییر میدهد (از Ice Lake شروع میشود)، اگرچه اینطور نیست. در این نسل از پردازنده ها، فناوری به نام “حرکت سریع کوتاه تکراری” اضافه شد. این برای تسریع عملیات مربوط به حرکت داده در RAM طراحی شده است. از جمله اینکه این فناوری می تواند اجرای دستور rep movsb را بهینه کند. همراه با ویژگی «تکرار سریع حرکت کوتاه»، نقصی در منطق پردازنده وجود داشت که ابتدا توسط مهندسان اینتل و بعداً توسط کارشناسان گوگل کشف شد.
تهدید فوری
اجرای این دستورالعمل که رفتار طبیعی پردازنده را مختل می کند، به چه چیزی می تواند منجر شود؟ به گفته Ormandy، نتایج غیر قابل پیش بینی است. محققان اجرای کد تصادفی، نادیده گرفته شدن بخشهایی از برنامه و خرابیهای مختلف در پردازنده را مشاهده کردند، تا زمانی که به شکست کامل رسید. برای دومی، باید به نحوی از آسیب پذیری روی یک جفت هسته پردازنده به طور همزمان سوء استفاده کرد. برای بررسی سیستم های خود از نظر این آسیب پذیری، تیمی از محققان گوگل یک برنامه آزمایشی آماده کردند.
رفتار غیرقابل پیش بینی به اندازه کافی بد است. مهمترین تفاوت بین این “اشکال پردازنده” و سایر موارد این است که مستقیماً ارائه دهندگان خدمات میزبانی سرور خصوصی مجازی یا به طور کلی ارائه دهندگان راه حل های ابری را تهدید می کند. این صنعت بر اساس توانایی به اشتراک گذاری یک سرور قدرتمند بین ده ها یا صدها مشتری ساخته شده است – هر کدام سیستم عامل مجازی خود را مدیریت می کنند. بسیار مهم است که تحت هیچ شرایطی یک مشتری نباید داده های مشتری دیگر یا داده های میزبان را ببیند – سیستم عاملی که کانتینرهای مجازی را مدیریت می کند.
حال تصور کنید که یک کلاینت می تواند برنامه ای را در سیستم عامل مجازی خود اجرا کند که باعث از کار افتادن هاست شود. حداقل، این می تواند یک حمله DoS به ارائه دهنده را فعال کند. در واقع، Ormandy هیچ سناریوی بهره برداری دیگری را ارائه نکرد و به این واقعیت اشاره کرد که پیش بینی رفتار پردازنده ای که در حالت جعبه سیاه کار می کند بسیار دشوار است. اگرچه از نظر تئوری ممکن است مهاجم به جای تکیه بر خرابی های تصادفی، کد مخرب خاصی را اجرا کند. خود نمایندگان اینتل اذعان دارند که “اجرای کد” و “افشای اطلاعات” امکان پذیر است. بنابراین، نصب بهروزرسانیهای میکروکد تهیهشده توسط اینتل (حداقل برای ارائهدهندگان خدمات میزبانی مجازی) بسیار مهم است.
ترجمه:
پیشگامان تجارت امن ایرانیان