ثيو دي رادت تخطط لتعزيز آلية حماية الذاكرة W^X (Write XOR Execute). جوهر الآلية هو أنه لا يمكن الوصول إلى صفحات ذاكرة العملية للكتابة والتنفيذ في وقت واحد. وبالتالي، لا يمكن تنفيذ التعليمات البرمجية إلا بعد تعطيل الكتابة، ولا يمكن الكتابة إلى صفحة الذاكرة إلا بعد تعطيل التنفيذ. تساعد آلية W^X على حماية تطبيقات مساحة المستخدم من هجمات تجاوز سعة المخزن المؤقت الشائعة، بما في ذلك تجاوزات سعة المكدس، وهي نشطة في OpenBSD .
منذ بداية العمل على W^X، كان من الواضح أن هذا طريق طويل، نظرًا لوجود عدد كبير من التطبيقات التي تستخدم JIT. يمكن تقسيم تطبيقات JIT إلى ثلاث فئات:
- تبديل الذاكرة بين حالتي W وX، وقبول "تكلفة" استدعاء النظام .
- إنشاء أسماء مستعارة بين زوج من تعيينات W وX لنفس الذاكرة.
- الخيار الأكثر "قذرة" هو تلك التي تتطلب نموذج ذاكرة W|X الذي يسمح بالتسجيل والتنفيذ المتزامن.
يوجد حاليًا عدد أقل بكثير من البرامج التي تستخدم الخيار الثالث والمزيد باستخدام الخيارين الأول والثاني. ومع ذلك، نظرًا لأنه كان من الضروري تشغيل البرامج باستخدام W|X JIT (بشكل أساسي Chromium وIridum)، تمت إضافة خيار تحميل نظام الملفات "wxallowed"، والذي يسمح باستخدام الذاكرة في وقت واحد لكل من الكتابة والتنفيذ، في حالة وجود ملف ELF القابل للتنفيذ. تم وضع علامة على الملف بعلامة "wxneeded"، وتمت حماية التطبيقات نفسها بشكل إضافي باستخدام الآليات и للحد من قائمة استدعاءات النظام المستخدمة وأجزاء نظام الملفات المتاحة للتطبيق، على التوالي.
ولزيادة تعقيد استغلال نقاط الضعف في مثل هذه التطبيقات، يُقترح إضافة إلى الآلية ، والذي يتحقق مما إذا كان يتم تنفيذ استدعاء النظام من صفحة ذاكرة قابلة للكتابة. إذا كانت الصفحة قابلة للكتابة، فسيتم فرض العملية على الإنهاء. بهذه الطريقة، لن يتمكن المهاجم من استغلال مكالمات النظام وسيضطر إلى محاولة العثور على الأدوات اللازمة في تنفيذ JIT أو حتى القيام بالعمل الأكثر صعوبة المتمثل في اكتشاف كعب مكالمات النظام مباشرة في الداخل .
عمليات Chrome/Iridium محمية بالفعل بشكل موثوق تمامًا باستخدام التعهد والكشف، ولكن من الواضح أن إزالة القدرة على الاستخدام، على سبيل المثال، استدعاء النظام write(2) له بعض المزايا، لأنه يخلق صعوبات إضافية للمهاجم. ومع ذلك، قد تنشأ صعوبات أيضًا إذا كان تطبيق JIT يستخدم استدعاءات النظام الأصلية من ذاكرة W|X. ومع ذلك، هناك سبب للأمل في ألا يكون هذا هو الحال، حيث تم تغيير واجهة التطبيق الثنائية (ABI) عدة مرات، ولكن لم يبلغ أحد عن المشكلات على الإطلاق.
التغييرات متاحة بالفعل في لقطات منتظمة لفرع OpenBSD-Current، وجميع المهتمين مدعوون للاختبار.
الأخبار ذات الصلة حول ظهور الوضع في Chrome/Iridium تستحق تعليقًا منفصلاً من Theo . من وجهة نظره، يعد هذا مقبولًا لبعض نماذج الاستخدام، ولكن ربما ليس للجميع، حيث من الواضح أن هذا الوضع سيزيد الحمل على المعالج. حاليًا، سيعمل Chrome في الغالب إذا قمت بتعطيل "wxallowed" لـ /usr/local، على الرغم من أنه قد تكون هناك مشكلات مع بعض الإضافات (ghostery مثال على ذلك). بطريقة أو بأخرى، يأمل ثيو أن يتم جلب العمل الكامل في وضع JITless إلى حالة التشغيل الكامل في المستقبل القريب.
المصدر: opennet.ru