مطالعه جزئیات حملات عملی که از حفاظت‌های MTE در Chrome و Linux عبور می‌کنند

جدول لینک‌ها

خلاصه

۱. مقدمه

۲. پیشینه

• افزونه برچسب‌گذاری حافظه
• حمله اجرای حدسی

۳. مدل تهدید

۴. یافتن گجت‌های نشت برچسب

• الگوی نشت برچسب
• فازینگ نشت برچسب

۵. گجت‌های TIKTAG

• TIKTAG-v1: بهره‌برداری از انقباض حدس‌زنی
• TIKTAG-v2: بهره‌برداری از فوروارد کردن ذخیره به بارگذاری

۶. حملات دنیای واقعی

۶.۱. حمله به Chrome

۷. ارزیابی

۸. کارهای مرتبط

۹. نتیجه‌گیری و مراجع

\

حملات دنیای واقعی

برای نشان دادن قابلیت بهره‌برداری از گجت‌های TIKTAG در کاهش مبتنی بر MTE، این بخش دو حمله دنیای واقعی علیه Chrome و هسته Linux را توسعه می‌دهد (شکل ۹). چندین چالش برای راه‌اندازی حملات دنیای واقعی با استفاده از گجت‌های TIKTAG وجود دارد. اول، گجت‌های TIKTAG باید در فضای آدرس هدف اجرا شوند، که نیاز به ساخت یا یافتن گجت‌ها از سیستم هدف توسط مهاجم دارد. دوم، مهاجم باید وضعیت کش را کنترل و مشاهده کند تا نتایج بررسی برچسب را نشت دهد. در ادامه، حملات دنیای واقعی را با استفاده از گجت‌های TIKTAG بر روی دو سیستم دنیای واقعی نشان می‌دهیم: مرورگر Google Chrome (بخش ۶.۱) و هسته Linux (بخش ۶.۲)، و استراتژی‌های کاهش را مورد بحث قرار می‌دهیم.

\ ۶.۱. حمله به Chrome

مرورگر یک مرورگر وب سطح حمله اولیه برای حملات مبتنی بر وب است زیرا محتوای وب غیرقابل اعتماد مانند JavaScript و HTML را پردازش می‌کند. ابتدا مدل تهدید را بررسی می‌کنیم (بخش ۶.۱.۱) و یک گجت TIKTAG ساخته شده در موتور JavaScript V8 ارائه می‌دهیم (بخش ۶.۱.۲). سپس، اثربخشی گجت‌های TIKTAG در بهره‌برداری از مرورگر را نشان می‌دهیم (بخش ۶.۱.۳) و استراتژی‌های کاهش را مورد بحث قرار می‌دهیم (بخش ۶.۱.۴).

\ ==۶.۱.۱. مدل تهدید.== ما از مدل تهدید معمولی حملات مرورگر Chrome پیروی می‌کنیم، جایی که مهاجم قصد دارد از آسیب‌پذیری‌های خرابی حافظه در فرآیند رندرر بهره‌برداری کند. فرض می‌کنیم کاربر قربانی از وب‌سایت تحت کنترل مهاجم بازدید می‌کند که یک صفحه وب مخرب ارائه می‌دهد. صفحه وب شامل HTML و JavaScript ساخته شده است که از آسیب‌پذیری‌های خرابی حافظه در فرآیند رندرر قربانی بهره‌برداری می‌کند. فرض می‌کنیم همه تکنیک‌های کاهش پیشرفته Chrome از جمله ASLR [18]، CFI [15]، جداسازی سایت [53] و V8 sandbox [56] در جای خود هستند. علاوه بر این، به عنوان یک دفاع متعامد، فرض می‌کنیم که فرآیند رندرر برچسب‌گذاری تصادفی MTE را در PartitionAlloc فعال می‌کند [2].

\ ==۶.۱.۲. ساخت گجت TIKTAG.== در محیط JavaScript V8، TIKTAG-v2 با موفقیت ساخته شد و برچسب‌های MTE هر آدرس حافظه را نشت داد. با این حال، ما یک گجت قابل ساخت TIKTAG-v1 پیدا نکردیم، زیرا محدودیت زمانی دقیق بین BR و CHECK در تکنیک فرار حدسی V8 sandbox ما امکان‌پذیر نبود (بخش A).

گجت V8 TikTag-v2. شکل ۸، گجت TIKTAG-v2 ساخته شده در موتور JavaScript V8 و کد شبه-C آن پس از کامپایل JIT است. با این گجت، مهاجم می‌تواند بفهمد که آیا برچسب حدس زده شده Tg با برچسب Tm اختصاص داده شده به target_addr مطابقت دارد یا خیر. مهاجم سه آرایه slow، victim، probe و یک مقدار idx آماده می‌کند. slow یک Unit8Array با طول ۶۴ است و در BR برای تحریک پیش‌بینی نادرست شاخه دسترسی می‌شود. victim یک Float64Array با طول ۶۴ است که برای تحریک فوروارد کردن ذخیره به بارگذاری دسترسی می‌شود. probe یک Uint8Array با طول ۵۱۲ است و در

\ TEST برای نشت نتیجه بررسی برچسب دسترسی می‌شود. یک مقدار idx از نوع Number در دسترسی خارج از محدوده victim استفاده می‌شود. مقدار idx به گونه‌ای انتخاب می‌شود که victim[idx] به target_addr با یک برچسب حدس زده شده Tg اشاره کند (یعنی (Tg«56)|target_addr). برای دسترسی حدسی به target_addr خارج از V8 sandbox، ما از تکنیک فرار حدسی V8 sandbox که در طول تحقیقات خود کشف کردیم استفاده کردیم که جزئیات آن را در بخش A ارائه می‌دهیم. خط ۸ شکل 8a بلوک BR گجت TIKTAG-v2 است که پیش‌بینی نادرست شاخه را با slow[0] تحریک می‌کند.

\ خط ۱۲-۱۳ بلوک CHECK است که فوروارد کردن ذخیره به بارگذاری را با victim[idx] انجام می‌دهد و به target_addr با یک برچسب حدس زده شده Tg دسترسی پیدا می‌کند. هنگامی که این کد JIT-compiled می‌شود (شکل 8b)، یک بررسی محدوده انجام می‌شود که idx را با victim.length مقایسه می‌کند. اگر idx یک شاخص خارج از محدوده باشد، کد undefined را برمی‌گرداند، اما اگر بارگذاری فیلد victim.length زمان زیادی طول بکشد، CPU به صورت حدسی دستورات ذخیره و بارگذاری بعدی را اجرا می‌کند.

\ پس از آن، خط ۱۷ بلوک TEST را پیاده‌سازی می‌کند که با مقدار فوروارد شده val به عنوان یک شاخص به probe دسترسی پیدا می‌کند. دوباره، یک بررسی محدوده بر روی val در برابر طول probe انجام می‌شود، اما این بررسی موفق است زیرا PROBE_OFFSET کوچکتر از طول آرایه probe است. در نتیجه، probe[PROBE_OFFSET] تنها زمانی کش می‌شود که فوروارد کردن ذخیره به بارگذاری موفق باشد، که در صورتی است که Tg با Tm مطابقت داشته باشد.

\ ==۶.۱.۳. حمله دور زدن MTE در Chrome.== شکل 9a حمله کلی دور زدن MTE بر روی مرورگر Chrome با نشت دلخواه برچسب گجت‌های TIKTAG را نشان می‌دهد. ما یک آسیب‌پذیری سرریز بافر در فرآیند رندرر فرض می‌کنیم، جایی که بهره‌برداری از یک آسیب‌پذیری زمانی (مثلاً use-after-free) تا حد زیادی یکسان است. این آسیب‌پذیری یک اشاره‌گر (یعنی vuln_ptr) به یک شیء آسیب‌پذیر (یعنی objvuln) را سرریز می‌کند و شیء مجاور (یعنی objtarget) را خراب می‌کند.

\ با اعمال MTE توسط PartitionAlloc، دو شیء با احتمال ۱۴/۱۵ برچسب‌های متفاوتی دارند. برای جلوگیری از ایجاد یک استثنا، مهاجم باید اطمینان حاصل کند که برچسب‌های objvuln و objtarget یکسان هستند. TIKTAG-v2 می‌تواند برای نشت برچسب objvuln (۱) و objtarget (۲) استفاده شود. اگر هر دو برچسب نشت داده شده یکسان باشند، مهاجم از آسیب‌پذیری بهره‌برداری می‌کند که خطای بررسی برچسب ایجاد نمی‌کند (۳). در غیر این صورت، مهاجم objtarget را آزاد کرده و دوباره تخصیص می‌دهد و به مرحله اول برمی‌گردد تا زمانی که برچسب‌ها مطابقت داشته باشند.

\ ==تحریک کانال جانبی کش.== برای بهره‌برداری موفق از یک گجت TIKTAG، مهاجم باید الزامات زیر را برآورده کند:

i) آموزش شاخه،

ii) کنترل کش، و

iii) اندازه‌گیری کش. هر سه الزام را می‌توان در JavaScript برآورده کرد.

اول، مهاجم می‌تواند پیش‌بینی‌کننده شاخه را با اجرای گجت با slow[0] غیرصفر و idx درون محدوده آموزش دهد، و پیش‌بینی نادرست شاخه را در BR با مقدار صفر در slow[0] و idx خارج از محدوده تحریک کند.

دوم، مهاجم می‌تواند خطوط کش slow[0]، victim.length و probe[PROBE_OFFSET] را با تکنیک‌های تخلیه کش JavaScript تخلیه کند [8، 21، 70].

سوم، مهاجم می‌تواند وضعیت کش probe[PROBE_OFFSET] را با یک تایمر با وضوح بالا بر اساس SharedArrayBuffer اندازه‌گیری کند [16، 58].

\ ==بهره‌برداری از آسیب‌پذیری‌های خرابی حافظه.== با توجه به برچسب‌های MTE نشت داده شده، مهاجم می‌تواند از آسیب‌پذیری‌های خرابی حافظه مکانی و زمانی در رندرر بهره‌برداری کند. استراتژی حمله تا حد زیادی مشابه حملات سنتی خرابی حافظه است اما باید اطمینان حاصل شود که آسیب‌پذیری با استفاده از برچسب‌های نشت داده شده، خطای بررسی برچسب ایجاد نمی‌کند. ما استراتژی حمله را در بخش C با جزئیات بیشتری توضیح می‌دهیم.

\ ==۶.۱.۴. کاهش.== برای کاهش حملات دور زدن MTE مبتنی بر گجت TIKTAG در فرآیند رندرر مرورگر، کاهش‌های زیر می‌تواند اعمال شود:

i) sandbox آگاه به اجرای حدسی: برای جلوگیری از راه‌اندازی حملات مبتنی بر TIKTAG از یک محیط sandbox مانند V8 sandbox توسط مهاجمان، sandbox می‌تواند با جلوگیری از هر دسترسی حدسی به حافظه فراتر از ناحیه حافظه sandbox تقویت شود. در حالی که مرورگرهای وب مدرن از sandbox برای جداسازی محتوای وب غیرقابل اعتماد از رندرر استفاده می‌کنند، اغلب مسیرهای حدسی را نادیده می‌گیرند.

\ به عنوان مثال، Chrome V8 sandbox [56] و Safari Webkit sandbox [1] به طور کامل مسیرهای حدسی را میانجی‌گری نمی‌کنند [27]. بر اساس تکنیک‌های فشرده‌سازی اشاره‌گر فعلی [64]، مسیرهای حدسی می‌توانند با پوشاندن بیت‌های بالای اشاره‌گرها به ناحیه sandbox محدود شوند.

\ ii) مانع حدس‌زنی: همانطور که در بخش ۵ پیشنهاد شد، قرار دادن یک مانع حدس‌زنی پس از BR برای گجت‌های TIKTAG بالقوه می‌تواند از حملات نشت برچسب حدسی جلوگیری کند. با این حال، این کاهش ممکن است در محیط مرورگر حساس به عملکرد قابل اعمال نباشد، زیرا ممکن است سربار عملکرد قابل توجهی ایجاد کند.

\ iii) جلوگیری از ساخت گجت: همانطور که در بخش ۵.۲ پیشنهاد شد، گجت TIKTAG-v2 می‌تواند با پد کردن دستورات بین دستورات ذخیره و بارگذاری کاهش یابد. یک گجت TIKTAGv1، اگرچه ما یکی قابل بهره‌برداری پیدا نکرده‌ایم، می‌تواند با پد کردن دستورات بین یک شاخه و دسترسی‌های حافظه کاهش یابد، همانطور که در بخش ۵.۱ توضیح داده شد.

\ ۶.۲. حمله به هسته Linux

هسته Linux بر روی ARM به طور گسترده برای دستگاه‌های موبایل، سرورها و دستگاه‌های IoT استفاده می‌شود که آن را به یک هدف حمله جذاب تبدیل می‌کند. بهره‌برداری از یک آسیب‌پذیری خرابی حافظه در هسته می‌تواند امتیاز کاربر را افزایش دهد، و بنابراین MTE یک مکانیسم حفاظتی امیدوارکننده برای هسته Linux است. حملات مبتنی بر TIKTAG علیه هسته Linux چالش‌های منحصر به فردی متفاوت از حمله مرورگر (بخش ۶.۱) ایجاد می‌کند.

\ این به این دلیل است که فضای آدرس مهاجم از فضای آدرس هسته که گجت در آن اجرا می‌شود جداست. در ادامه، ابتدا مدل تهدید هسته Linux را بررسی می‌کنیم (بخش ۶.۲.۱) و یک گجت اثبات مفهوم TIKTAG که در هسته Linux کشف کردیم ارائه می‌دهیم (بخش ۶.۲.۲). در نهایت، اثربخشی گجت‌های TIKTAG در بهره‌برداری از آسیب‌پذیری‌های هسته Linux را نشان می‌دهیم (بخش ۶.۲.۳).

\ ==۶.۲.۱. مدل تهدید.== مدل تهدید در اینجا تا حد زیادی همان حملات معمولی افزایش امتیاز علیه هسته است. به طور خاص، ما بر روی هسته Linux مبتنی بر ARM اندروید تمرکز می‌کنیم که با حفاظت‌های پیش‌فرض هسته (مثلاً KASLR، SMEP، SMAP و CFI) سخت شده است. ما همچنین فرض می‌کنیم که هسته با یک راه‌حل برچسب‌گذاری تصادفی MTE مشابه راه‌حل‌های آماده تولید MTE، Scudo سخت شده است [3].

\ به طور خاص، هر شیء حافظه به طور تصادفی برچسب‌گذاری می‌شود، و یک برچسب تصادفی هنگامی که یک شیء آزاد می‌شود اختصاص داده می‌شود، بنابراین از هر دو خرابی حافظه مکانی و زمانی جلوگیری می‌کند. مهاجم قادر به اجرای یک فرآیند بدون امتیاز است و قصد دارد با بهره‌برداری از آسیب‌پذیری‌های خرابی حافظه در هسته، امتیاز خود را افزایش دهد. فرض بر این است که مهاجم آسیب‌پذیری‌های خرابی حافظه هسته را می‌داند اما هیچ برچسب MTE از حافظه هسته را نمی‌داند. تحریک خرابی حافظه بین اشیاء هسته با

\ برچسب‌های نامطابق یک خطای بررسی برچسب ایجاد می‌کند که برای بهره‌برداری‌های دنیای واقعی نامطلوب است. یک چالش حیاتی در این حمله این است که گجت باید با استفاده مجدد از کد موجود هسته ساخته شود و توسط فراخوانی‌های سیستمی که مهاجم می‌تواند فراخوانی کند اجرا شود. از آنجایی که معماری ARMv8 جداول صفحه کاربر و هسته را جدا می‌کند، گجت‌های فضای کاربر نمی‌توانند به صورت حدسی به حافظه هسته دسترسی داشته باشند. این تنظیم بسیار متفاوت از مدل تهدید حمله به مرورگر (بخش ۶.۱) است که از کد ارائه شده توسط مهاجم برای ساخت گجت استفاده کرد. ما ساخت گجت مبتنی بر eBPF را نیز حذف کردیم [17، 28]، زیرا eBPF برای فرآیند اندروید بدون امتیاز در دسترس نیست [33].

\ ==۶.۲.۲. گجت Kernel TikTag==. همانطور که در بخش ۴.۱ توضیح داده شد، گجت‌های TIKTAG باید چندین الزام را برآورده کنند، و هر الزام مستلزم چالش‌هایی در محیط هسته است.

اول، در BR، یک پیش‌بینی نادرست شاخه باید با cond_ptr تحریک شود، که باید از فضای کاربر قابل کنترل باشد. از آنجایی که پردازنده‌های AArch64 اخیر آموزش پیش‌بینی شاخه را بین کاربر و هسته جدا می‌کنند [33]، آموزش شاخه باید از فضای هسته انجام شود.

دوم، در CHECK، guess_ptr باید ارجاع داده شود. guess_ptr باید از فضای کاربر ساخته شود به گونه‌ای که یک برچسب حدس (Tg) را جاسازی کند و به آدرس هسته (یعنی target_addr) اشاره کند تا برچسب (Tm) را نشت دهد. برخلاف محیط JavaScript مرورگر (بخش ۶.۱)، داده‌های ارائه شده توسط کاربر به شدت در فراخوانی‌های سیستم ضدعفونی می‌شوند، بنابراین ایجاد یک اشاره‌گر دلخواه هسته دشوار است.

\ به عنوان مثال، access_ok() اطمینان حاصل می‌کند که اشاره‌گر ارائه شده توسط کاربر به فضای کاربر اشاره می‌کند، و ماکرو array_index_nospec از دسترسی حدسی خارج از محدوده با شاخص ارائه شده توسط کاربر جلوگیری می‌کند. بنابراین، guess_ptr باید یک اشاره‌گر موجود هسته باشد، به طور خاص اشاره‌گر آسیب‌پذیری که باعث خرابی حافظه می‌شود. به عنوان مثال، یک اشاره‌گر معلق در use-after-free (UAF) یا یک اشاره‌گر خارج از محدوده در سرریز بافر می‌تواند استفاده شود. در نهایت، در TEST، test_ptr باید ارجاع داده شود، و test_ptr باید از فضای کاربر قابل دسترسی باشد. برای تسهیل اندازه‌گیری وضعیت کش، test_ptr باید یک اشاره‌گر فضای کاربر ارائه شده از طریق یک آرگومان فراخوانی سیستم باشد.

\ ==گجت‌های کشف شده.== ما به صورت دستی کد منبع هسته Linux را تجزیه و تحلیل کردیم تا گجت TIKTAG را که الزامات فوق را برآورده می‌کند پیدا کنیم. در نتیجه، ما یک گجت بالقوه قابل بهره‌برداری TIKTAG-v1 در snd_timer_user_read() پیدا کردیم (شکل ۱۰). این گجت الزامات TIKTAG-v1 را برآورده می‌کند (بخش ۵.۱). در خط ۱۰ (یعنی BR)، دستور switch پیش‌بینی نادرست شاخه را با یک مقدار قابل کنترل توسط کاربر tu->tread (یعنی cond_ptr) تحریک می‌کند. در خطوط ۱۴-۱۷ (یعنی CHECK)، tread (یعنی guess_ptr) توسط چهار دستور بارگذاری ارجاع داده می‌شود. tread به یک شیء struct snd_timer_tread64 اشاره می‌کند که مهاجم می‌تواند به طور دلخواه تخصیص دهد و آزاد کند.

\ اگر یک آسیب‌پذیری زمانی tread را به یک اشاره‌گر معلق تبدیل کند، می‌تواند به عنوان یک guess_ptr استفاده شود. در خط ۲۰، (یعنی TEST)، یک اشاره‌گر فضای کاربر buffer (یعنی test_ptr) در copy_to_user ارجاع داده می‌شود. از آنجایی که این گجت مستقیماً از فضای کاربر قابل دسترسی نیست، ما یک تغییر جزئی در کد هسته ایجاد کردیم؛ ما بازگشت زودهنگام را برای حالت پیش‌فرض در خط ۶ حذف کردیم. این تضمین می‌کند که buffer تنها در مسیر حدسی برای مشاهده تفاوت وضعیت کش به دلیل اجرای حدسی دسترسی پیدا می‌کند.

\ اگرچه این اصلاح در یک سناریوی دنیای واقعی واقع‌بینانه نیست، اما قابلیت بهره‌برداری بالقوه گجت را در صورت انجام تغییرات مشابه کد نشان می‌دهد. ما چندین گجت بالقوه قابل بهره‌برداری دیگر کشف کردیم، اما نتوانستیم تفاوت وضعیت کش بین تطابق و عدم تطابق برچسب را مشاهده کنیم. با این حال، ما فکر می‌کنیم پتانسیل قوی برای بهره‌برداری از آن گجت‌ها وجود دارد. راه‌اندازی حملات مبتنی بر TIKTAG شامل مهندسی پیچیده و حساس است، و بنابراین ما نتوانستیم با همه موارد ممکن آزمایش کنیم.

\ به ویژه، TIKTAG-v1 بر انقباض حدس‌زنی در رویدادهای مسیر اشتباه متکی است، که ممکن است شامل خطاهای ترجمه آدرس یا استثناهای دیگر در مسیر پیش‌بینی نادرست شاخه نیز باشد. از آنجایی که فراخوانی‌های سیستم شامل جریان‌های کنترل پیچیده هستند، انقباض حدس‌زنی ممکن است همانطور که انتظار می‌رود تحریک نشود. علاوه بر این، چندین گجت ممکن است با تغییرات کد هسته قابل بهره‌برداری شوند. به عنوان مثال، یک گجت TIKTAG-v1 در ip6mr_ioctl() رفتار نشت برچسب MTE را هنگام فراخوانی از مسیر فراخوانی سیستم خود (یعنی ioctl) نشان نداد. با این حال، گجت هنگامی که به سایر فراخوانی‌های سیستم (مثلاً write) با یک جریان کنترل ساده منتقل شد، نشت برچسب داشت.

\ ==۶.۲.۳. حمله دور زدن MTE هسته.== شکل 9b حملات دور زدن MTE بر روی هسته Linux را نشان می‌دهد. با در نظر گرفتن یک آسیب‌پذیری use-afterfree به عنوان مثال، فرض می‌کنیم مهاجم یک گجت TIKTAG مربوطه، SysTikTagUAF()، را شناسایی کرده است که قادر به نشت نتیجه بررسی برچسب اشاره‌گر معلق ایجاد شده توسط آسیب‌پذیری است. به عنوان مثال، گجت TIKTAG-v1 در snd_timer_user_read() (شکل ۱۰) می‌تواند نتیجه بررسی برچسب tread را نشت دهد، که می‌تواند توسط یک آسیب‌پذیری use-after-free یا double-free به یک اشاره‌گر معلق تبدیل شود.

\ حمله به شرح زیر پیش می‌رود: اول، مهاجم یک شیء هسته (یعنی objvuln) را آزاد می‌کند و اشاره‌گر آن (یعنی vuln_ptr) را به عنوان یک اشاره‌گر معلق باقی می‌گذارد (۱). سپس، مهاجم یک شیء هسته دیگر (یعنی objtarget) را در آدرس objvuln با SysAllocTarget() تخصیص می‌دهد (۲). سپس، مهاجم SysTikTag() را با یک بافر فضای کاربر (یعنی ubuf) فراخوانی می‌کند (۳)، و نتیجه بررسی برچسب (یعنی Tm == Tg) را با اندازه‌گیری تأخیر دسترسی ubuf نشت می‌دهد (۴). اگر برچسب‌ها مطابقت داشته باشند، مهاجم SysExploitUAF()، یک فراخوانی سیستم که از آسیب‌پذیری use-after-free بهره‌برداری می‌کند را تحریک می‌کند (۵). در غیر این صورت، مهاجم objtarget را دوباره تخصیص می‌دهد تا زمانی که برچسب‌ها مطابقت داشته باشند.

\ ==تحریک کانال جانبی کش.== همانند بخش ۶.۱.۳، بهره‌برداری موفق از گجت TIKTAG نیاز به i) آموزش شاخه، ii) کنترل کش، و iii) اندازه‌گیری کش دارد. برای آموزش شاخه، مهاجم می‌تواند پیش‌بینی‌کننده شاخه را آموزش دهد و حدس‌زنی را با شرایط شاخه کنترل شده توسط کاربر از فضای کاربر تحریک کند. برای کنترل کش، مهاجم می‌تواند بافر فضای کاربر (یعنی ubuf) را فلاش کند، در حالی که آدرس حافظه هسته می‌تواند با پرش خط کش تخلیه شود [25]. برای اندازه‌گیری کش، تأخیر دسترسی ubuf می‌تواند با شمارنده مجازی (یعنی CNTVCT_EL0) یا یک تایمر مبتنی بر شمارنده حافظه (یعنی وضوح نزدیک به چرخه CPU) اندازه‌گیری شود.

\ ==بهره‌برداری از آسیب‌پذیری‌های خرابی حافظه.== گجت‌های TIKTAG امکان دور زدن MTE و بهره‌برداری از آسیب‌پذیری‌های خرابی حافظه هسته را فراهم می‌کنند. مهاجم می‌تواند گجت TIKTAG را در هسته فراخوانی کند تا به صورت حدسی خرابی حافظه را تحریک کند و نتیجه بررسی برچسب را به دست آورد. سپس، مهاجم می‌تواند نتیجه بررسی برچسب را به دست آورد، و تنها در صورتی که برچسب‌ها مطابقت داشته باشند، خرابی حافظه را تحریک کند. ما فرآیند حمله دور زدن MTE هسته Linux را در بخش D با جزئیات توضیح می‌دهیم.

\ ==۶.۲.۴. کاهش.== برای کاهش گجت TIKTAG در هسته Linux، توسعه‌دهندگان هسته باید کاهش‌های زیر را در نظر بگیرند:

i) مانع حدس‌زنی: موانع حدس‌زنی می‌توانند به طور مؤثر گجت TIKTAG-v1 را در هسته Linux کاهش دهند. برای جلوگیری از نشت نتیجه بررسی برچسب از طریق بافر فضای کاربر توسط مهاجمان، توابع هسته که به آدرس‌های فضای کاربر دسترسی دارند، مانند copy_to_user و copy_from_user، می‌توانند با موانع حدس‌زنی سخت شوند. همانطور که در بخش ۵.۱ توضیح داده شد، نشت نتایج بررسی برچسب با دسترسی ذخیره می‌تواند با قرار دادن یک مانع حدس‌زنی قبل از دسترسی ذخیره (یعنی TEST) کاهش یابد.

\ به عنوان مثال، برای کاهش گجت‌های استفاده کننده از copy_to_user، یک مانع حدس‌زنی می‌تواند قبل از فراخوانی copy_to_user درج شود. برای گجت‌های استفاده کننده از دسترسی بارگذاری به بافر فضای کاربر، موانع گجت‌ها را در صورت درج بین شاخه و دسترسی حافظه هسته (یعنی CHECK) کاهش می‌دهند. به عنوان مثال، برای کاهش گجت‌های استفاده کننده از copy_from_user، توسعه‌دهندگان هسته باید به دقت پایگاه کد هسته را تجزیه و تحلیل کنند تا الگوی شاخه شرطی، دسترسی حافظه هسته، و copy_from_user() را پیدا کنند، و یک مانع حدس‌زنی بین شاخه و دسترسی حافظه هسته درج کنند.

\ ii) جلوگیری از ساخت گجت: برای حذف گجت‌های بالقوه TIKTAG در هسته Linux، کد منبع هسته می‌تواند تجزیه و تحلیل و وصله شود. از آنجایی که گجت‌های TIKTAG همچنین می‌توانند توسط بهینه‌سازی‌های کامپایلر ساخته شوند، یک تحلیل باینری می‌تواند انجام شود. برای هر گجت کشف شده، دستورات می‌توانند مرتب شوند یا دستورات اضافی می‌توانند برای جلوگیری از ساخت گجت، پیروی از استراتژی‌های کاهش در بخش‌های ۵.۱ و ۵.۲، درج شوند.

:::info نویسندگان:

1. Juhee Kim
2. Jinbum Park
3. Sihyeon Roh
4. Jaeyoung Chung
5. Youngjoo Lee
6. Taesoo Kim
7. Byoungyoung Lee

:::

:::info این مقاله در arxiv موجود است تحت مجوز CC 4.0.

:::

\