پردازندههای اینتل (Intel) درمواجههبا اسکریپتهای فراریسمانی (HyperThread) مخربی هستند که با سوءاستفاده از حفرهی پردازشی، کلیدهای خصوصی و عمومی کیفپول رمزارزها را شناسایی میکنند و میربایند. بهموازات آن، مشاهدهشدن همین آسیبپذیری که از نوع Side-Channel است، در سری پرادازندههای اسکایلیک (SkyLake) و کبیلیک (KabyLake)، بهنظر میرسد شرایط مشابه برای پردازندههای AMD هم وجود داشته باشد.
طی یازده ماه گذشته، پردازندههای کامپیوترها و بعضا گوشیهای موبایل، به بستری برای اجرای حملات مخرب تبدیل شدهاند. نامهای منفوری نظیر Meltdown and Spectre ،BranchScope ،TLBleed و Foreshadow متعلق به کدهای مخربی هستند که تهدیدی برای سرقت اطلاعات محرمانهی ما نظیر رمزهایمان و کلید خصوصی کیفپولهایمان از پردازندهها محسوب میشوند. این بهگونهای است که با سازوکارهای تدافعی ساده و سنّتی نمیتوان آنها را شناسایی و متوقف کرد. در همین زمینه، ماه گذشته پژوهشگران اعلام کردند یکی از حفرههای امنیتی که پیشازاین در تعداد زیادی از پردازندههای اینتل شناسایی شده بود، با وجود برطرفشدن مشکل بهصورت نرمافزاری کماکان وجود دارد و حملات جدیدی برپایهی آن طرحریزی شده و احتمال وقوع دارد. این تهدید برای پردازندههای غیراینتلی هم متصور است.
این حمله جدید که نامش PortSmash است، از محل حفرهی مغفولماندهی نوع Side-Channel در فناوری فراریسمانی اینتل صورت میگیرد. این فناوری فراریسمانی نوع خاص و ارتقایافتهای از فناوری چندریسمانی همزمان است که سرعت اجرای حجم زیادی از فرمانهای محاسباتی را افزایش میدهد که باید همزمان و موازی اجرا شوند. در این معماری، کل توان پردازشی تولیدشده هم برآمده از فعالیت دو هستهی پردازش مجازی است که روی پردازندهای فیزیکی بنا شدهاند. هستههای اضافهشده تقسیم فرمانهای محاسباتی بزرگ به فرمانهای ساده و کوچکتر را تسهیل میکنند؛ درنتیجه، اجرای آنها سریعتر انجام میشود.
ترافیک تبادلی در درگاههای ارتباطی پردازندهها و حفرهای از نوع Side-Channel
پژوهشگران در سندی که بهزودی آن را منتشر میکنند، فرایند سرقت داده از سرور OpenSSL و بازیابی کلید خصوصی موجود در آن دادهها ازطریق همین نقصان تازهکشفشده را تشریح میکنند. مکانیزم این حمله که روی سرورها با پردازندههای اسکایلیک و کبیلیک اینتل و سیستمعامل اوبونتو صورت میگیرد، بدینترتیب است که جریان پایدار و متراکمی از کدهای اجرایی را به یکی از آن هستههای مجازی پردازنده میفرستند و بادقت زمان پردازش و اجرای آنها را میسنجد تا به مدل تخصیص وظایف به درگاهها و زمانبندی آنها پی ببرد.
باتوجهبه الگوی زمانبندی منحصربهفرد موجود در این پردازندهها و تکنیکی که برای تخصیص آن جریان پردازش به درگاهها طراحی شده، درنتیجه میتوان پردازنده را مجبور کرد همهی پردازشهای غیرمرتبط با این جریان ساختگی را به هستهی دیگر منتقل کند و در زمانیکه آن هسته مشغول پردازش کلیدهای خصوصی است، دادههای رمزشده ربوده و رمزگشایی شوند.
آنچه زمینهی این نفوذ را فراهم میکند، مفهومی است بهنام «ترافیک تبادلی بین درگاههای پردازنده» (Port Contention) و زمانی رخ میدهد که در پردازندهای فیزیکی رستهای از دستورالعملها به درگاههای مختلف برای پردازش تخصیص داده میشوند و در صف اجرا قرار میگیرند. این آسیبپذیری با عبارت CVE-2018-5407 کدگذاری شده است. هم کامپیوترهای شخصی و هم سرورها در معرض چنین آسیبی قرار دارند؛ هرچند دراینمیان سرورهای بیشتر مدنظر مهاجمان هستند.
پژوهشگران در این سند آوردهاند:
تکنیکی که برای انتخاب درگاههای هدف برای ارسال جریان محاسبات طراحی کردهایم اینگونه است که با انتخاب چندین پیکربندی ازپیشآماده و اعمال آنها روی پردازنده، زمینه را برای اجرای چند سناریوی شناسایی پردازشهای خاص روی هستهی دیگر فراهم میکنیم که حکم طعمه را دارد. PortSmash انتقالپذیری بسیاری دارد؛ به این معنا که بهراحتی قابل نشر و استقرار در رایانههای مختلف است و حداقل پیشنیازها را برای اجرا لازم دارد. برای بهرهگیری از آن نه نیازی به آشنایی با تکنیکهای یادگیری ماشین هست و نه نیاز به آشنایی با تکنیک مهندسی معکوس.
بیلیباب بروملی (Billy Bob Brumly)، استاد دانشکدهی فنی دانشگاه Tampere فنلاند و یکی از نویسندگان این سند، در مصاحبهای اینگونه عنوان میکند:
انتظار میرود پردازندههایی که فناوری آنها از سریهای اسکایلیک و کبیلیک قویتر است، نیز آسیبپذیر باشند و با کمی دستکاری کدها بتوان به آنها نیز نفوذ کرد. بهشدت به معماری پردازندههای رایزنAMD هم شک دارم که از فناوری SMT استفاده میکنند؛ اما بهدلیل اینکه درحالحاضر تجهیزات و سختافزار کافی برای آزمایش آنها ندارم، این کار را به وقتی دیگر موکول کردهام.
بروملی معتقد است زیرساختهای IaaS بهترین محیط از منظر انطباق با شرایط واقعی برای آزمودن و سنجش نقاط نفوذ و آسیبپذیر است؛ چراکه آنها در بستر ابری، همهی ظرفیتهای لازم برای دیتاسنتری مثل سرور، فضای ذخیرهسازی، سختافزارهای شبکه و همچنین شبیهسازها رای رصد و نظارت را دربردارند.
بروملی همچنین در این سند نوشته است:
بهشخصه معتقدم همین دسترسیهای راه دور (Remote Logins) جدیترین تهدیدها و نقطه شروع این حملات هستند. کاربر خرابکار با دسترسیهای کافی مثلا با SSH به سیستم وارد میشود و کد مخرب را پردازش و اجرا میکند و دادههای مربوطبه هستهی دیگر را بهدست میآورد که حاوی کلیدهای خصوصی است.
این کد به زبان اسمبلی ۶۴ بیتی تولید شده و باید روی خود دستگاه آسیبپذیر اجرا شود و نه از راه دور. البته، به کمک مکانیزمهایی که در حملات Spectre بهکار میرود، میتوان این کد را در بطن Javascript به روی سیستم فرستاد. تاکنون، چنین موردی مشاهده نشده؛ اما احتمال آن همواره متصور است. نمونهای از کدهای پژوهشگران دراینباره را میتوانید در اینجا ببینید.
اینتل رسما در بیانیهای اعلام کرده است:
این موضوع ارتباطی به تکنیک اجرای زودهنگام محاسبات (Speculative Execution) ندارد. پس، با Spectre و Meltdown یا نقص ترمینال L1 هم نامرتبط است و فکر میکنیم فقط به پلتفرمهای اینتلی هم محدود نباشد. غالبا محور روشهای حملات Side-Channel، سنجش و دستکاری برخی مقادیر کنترلی منبع سختافزاری بهاشتراک گذاشتهشده نظیر زمانبندی جریان ارسال دستورالعملها روی درگاههای یکی از پردازندهها است. نرمافزارهای سیستمی و کتابخانههای برنامهنویسی را میتوان با اجرای الگوهای ایمنسازی موجودی که برای حملات Side-Channel وجود دارد، از این دستکاریها مصون نگاه داشت. بااینحال، حفاظت از دادههای مشتریان و اطمینان از اینکه محصولاتمان در سطح مناسبی از امنیت قرار دارند، اولویت اول ماست و برای حفظ این مهم، همکاری خود را با مشتریان و شرکا و پژوهشگران بهمنظور کشف و کاهش نقاط آسیبپذیر همواره ادامه خواهیم داد.
فناوری فراریسمانی محکوم به نابودی
PortSmash دومین حملهی پردازندهای است که همین قابلیت فراریسمانی را هدف قرار میدهد. حملهی دیگری بهنام TLBleed که در خرداد شناسایی شد هم با استفاده از همین فناوری در پی یافتن کلید خصوصی در رمزنگاریها بود. پژوهشگران که این حمله را طرحریزی کرده و توسعه دادهاند، با استفاده از الگوریتم Cruve 25519 EdDSA موجود در کتابخانه libgcrypt برنامهای برای کشف و بازیابی امضاهای رمزنگاری (Cryptographic Signitures) تولید کردند و آن را روی یکی از هستههای مجازی قرار دادند. بههمان شیوهای که توضیح داده شد، این کد درگیر شناسایی کلیدهای خصوصی شد. آنها با این کار موفق شدند در ترکیب زمانی که دو میلیثانیهی آن برای ارزیابی و رصد ترافیک درگاهها، هفده ثانیه برای فرایند حدس و تخمین در چهارچوب عملیات یادگیری ماشین و نهایتا یک ثانیه هم برای تخمین پیچیدهی خطی صرف شده بود، کلید ۲۵۶ بیتی را بهدست آورند که برای تولید امضاها استفاده میشد. این حملهی Side-Channel در حافظهی TLB پردازندهی فیزیکی میزبانی و اجرا شد.
پیشازاین، مکانیزم حملهی TLBleed بهحدی نگرانکننده بود که توسعهدهندگانی که روی پلتفرم OpenBSDفعالیت میکردند، به غیرفعالکردن ویژگی فراریسمانی پردازنده مجبور میکرد. بروملی در جایی توصیه کرده کاربران قابلیت SMT را از تنظیمات BIOS هم غیرفعال کنند یا اینکه از تجهیزاتی استفاده کنند که اصلا چنین قابلیتی نداشته باشند. او حتی اعتقاد دارد بهتر است توسعهدهندگان سیستمعاملها در لحظه راهاندازی به کل SMT را غیرفعال کنند.
الکساندر پسلیاک (Alexander Peslyak) صاحبنظر حوزهی امنیت که بیشتر با نام مستعار SolarDesignerشناخته میشود، در تمجید از این پروژهی تحقیقاتی روی فناوری فراریسمانی، آن را پژوهشی درجهیک نامیده و گفته است:
رخداد حملههای نوع Side-Channel که با سنجش و ارزیابی ترافیک تبادلی درگاهها صورت میپذیرد، دورازانتظار نبود. باوجوداین، مشکل اینجاست که تاکنون کسی آن را مستند نکرده بود. شاید بهتر بود همان سال ۱۹۸۴، بیشتر برای شناساندن آن تلاش میکردیم؛ درست مانند همین پژوهشی که اکنون انجام شده است.
همچنین طبق اظهارات او، ساختار آن نسخه از OpenSSL که PortSmash با سوءاستفاده از آن این اقدامات مخرب را انجام میدهد، بهگونهای است که حتی با غیرفعالبودن SMT نیز امکان سرقت کلیدهای خصوصی وجود دارد. البته بدیهی است برای این کار به منابع و زمان نیاز بیشتری وجود دارد.
اشکالات موجود در خود OpenSSL
پائول کوچر (Paul Kocher)، کارشناس امنیت و رمزنگاری که پژوهش مشابه را درخصوص Spectre انجام داده، اعتقاد دارد ضعف مهمی که PortSmash را بسیار خطرناکتر میکند، شیوهی اجرای عملیات حساس بهوسیلهی OpenSSL است؛ بهنحویکه از دستورالعملهای انشعابی استفاده میکند که حاوی مقادیر محرمانه هستند.
دراینباره او چنین اظهارنظر کرده است:
تولیدکنندگان کتابخانههای برنامهنویسی برای رمزارزها از پیش از چنین حفرههای امنیتی باخبر هستند و میدانند باید مسیر دسترسیهای آنها را مسدود کنند. آنها معمولا معتقدند باید از بهوجودآمدن هر شرایطی جلوگیری کرد که در آن، دادههای محرمانه در جریان پردازش قرار دارند، مثل دستورالعملهای شرطی و انشعابی. ازاینرو، میتوان نتیجه گرفت که محل نفوذ و آسیبرسانی همین حملههای متکی به فناوری فراریسمانی و شاید هم متکی به مکانیزمهای دیگر مثل پیشبینی پرشها (Branch Predictor)، اشکالی است که در OpenSSL وجود دارد.
توسعهدهندگان OpenSSL از آن زمان نسخهی بهروزرسانی را منتشر کردهاند که فعالیت PortSmash را ناممکن میکند. جزئیاتی از تغییرات حاصل از این بهروزرسانی دردست نیست؛ اما احتمال میرود آنها تغییراتی را در شیوهی تعامل OpenSSL با SMT اعمال کردهاند.
سند منتشرشده برای PortSmash که با عنوان «ترافیک تبادلی درگاهها مایهی تفریح و درآمدزایی» است، بارها بر غیرفعالکردن SMT تأکید میکند. البته نه صرفا برای توضیح تهدیدهای PortSmash، بلکه TLBleed و حملات مشابه CashBleed و MemJam هم در دامنهی توصیهی آن قرار دارند. نویسندگان سند همچنین بهدنبال اندازهگیری میزان افت پردازشی هستند که ناشی از اعمال راهکارهای دفاعی روی برنامههای کاربردی با تراکم ریسمانهای پردازشی است.
یکی از راهکارهای دفاعی که میتواند افت پردازش کمی بهدنبال داشته باشد، اعمال تغییراتی در کتابخانههای مرتبطبا کرنل (Library OS) است که بهموجب آن در زمان اجرای فرمانهای بهوسیلهی برنامههای کاربردی، هستههای مجازی پردازنده ایزوله و مصون میشوند.
میتوانیم SMT را غیرفعال کنیم تا توان پردازشی بیشتر کاهش یابد؛ اما اعمال تغییرات در این کتابخانهها، مستلزم زمان زیاد و اصلاحات گستردهای در کتابخانهها است.
رویکرد دفاعی دیگری که این پژوهشگران توصیه کردهاند، تولید کدهای مستقل از درگاه (Port-Independent) در توسعهی برنامههای کاربردی است؛ بهنحویکه مثل اجراهای زمان-ثابت (Constant-Time)، با الگوهای کدنویسی امنی که مستقل از رمز (Secret-Independent) هستند، این برنامهها تولید شوند.
برای تأکید مجدد، PortSmash اکنون برای کاربرانی تهدید بهحساب میآید که رایانه آنها به هر دلیلی به منابع نامطمئن اجازهی اجرای پردازش روی پردازندهی فیزیکیاش را میدهد. این کاربران باید بهدقت این سند را مطالعه کنند و توصیههای آن را جدی بگیرند. با اینکه بهنظر میرسد، خطر این موضوع برای سایر کاربران کمتر است؛ اما ممکن است با تحقیق و بررسی بیشتر، مواردی درخصوص آسیبپذیری آنان نیز مشخص شود.
0 دیدگاه