برنامه هایی برای تقویت مکانیسم امنیتی W^X OpenBSD

تئو دی رادت مشترک قصد دارد مکانیسم حفاظت از حافظه W^X (Write XOR Execute) را تقویت کند. ماهیت مکانیزم این است که به صفحات حافظه پردازشی نمی توان به طور همزمان برای نوشتن و اجرا دسترسی داشت. بنابراین، کد فقط پس از غیرفعال شدن نوشتن قابل اجرا است و نوشتن در صفحه حافظه تنها پس از غیرفعال شدن اجرا امکان پذیر است. مکانیسم W^X به محافظت از برنامه‌های فضای کاربر در برابر حملات رایج سرریز بافر، از جمله سرریزهای پشته کمک می‌کند و در OpenBSD فعال است. به طور پیش فرض.

از زمان شروع کار بر روی W^X، مشخص بود که این راه طولانی است، زیرا تعداد قابل توجهی از برنامه های کاربردی با استفاده از JIT وجود داشت. پیاده سازی JIT را می توان به سه دسته تقسیم کرد:

• جابجایی حافظه بین حالت های W و X، پذیرش "هزینه" تماس سیستم mprotec.
• ایجاد نام مستعار بین یک جفت نگاشت W و X از یک حافظه.
• کثیف ترین گزینه به یک مدل حافظه W|X نیاز دارد که امکان ضبط و اجرای همزمان را فراهم می کند.

در حال حاضر، تعداد برنامه های کمتری از گزینه سوم استفاده می شود و تعداد بیشتری از برنامه های اول و دوم استفاده می شود. با این حال، از آنجایی که اجرای برنامه‌ها با W|X JIT (عمدتاً Chromium و Iridum) ضروری بود، یک گزینه "wxallowed" برای نصب فایل سیستم اضافه شد که امکان استفاده همزمان از حافظه برای نوشتن و اجرا را فراهم می‌کرد، در صورتی که ELF قابل اجرا باشد. فایل با نشانگر "wxneeded" علامت گذاری شده است و خود برنامه ها نیز با استفاده از مکانیسم ها محافظت می شوند گرو и پرده برداری برای محدود کردن لیست تماس های سیستمی استفاده شده و بخش هایی از سیستم فایل در دسترس برنامه، به ترتیب.

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

فرآیندهای کروم/ایریدیوم در حال حاضر کاملاً قابل اعتماد با استفاده از تعهد و آشکارسازی محافظت می‌شوند، اما حذف توانایی استفاده از، برای مثال، فراخوانی سیستم نوشتن (2) بدیهی است که مزیت‌هایی دارد، زیرا مشکلات بیشتری برای مهاجم ایجاد می‌کند. با این حال، اگر پیاده سازی JIT از فراخوانی سیستم بومی از حافظه W|X استفاده کند، ممکن است مشکلاتی نیز پیش بیاید. با این حال، دلیلی برای امیدواری وجود دارد که اینگونه نباشد، زیرا ABI چندین بار تغییر کرده است، اما هیچ کس تا کنون مشکلاتی را گزارش نکرده است.

تغییرات در حال حاضر در اسنپ شات های معمولی از شعبه OpenBSD-Current موجود است، از همه علاقه مندان دعوت به آزمایش می شود.

اخبار مرتبط در مورد ظاهر حالت در کروم/ایریدیوم مستحق نظر جداگانه ای از طرف Theo است بدون JIT. از دیدگاه او، این برای برخی از مدل‌های استفاده قابل قبول است، اما احتمالاً برای همه نه، زیرا این حالت بدیهی است که بار روی پردازنده را افزایش می‌دهد. در حال حاضر، اگر «wxallowed» را برای /usr/local غیرفعال کنید، کروم بیشتر کار می‌کند، اگرچه ممکن است در برخی از برنامه‌های افزودنی مشکلاتی وجود داشته باشد (به عنوان مثال ghostery). به هر حال، تئو امیدوار است که کار تمام عیار در حالت JITless در آینده نزدیک به حالت کاملاً عملیاتی برسد.

منبع: opennet.ru