درع تنفيذي

مشروع Exec Shield هو مشروع بدأ في شركة Red Hat أواخر عام 2002 بهدف الحد من مخاطر هجمات الديدان أو غيرها من الهجمات الآلية عن بُعد على أنظمة Linux. وكانت أولى نتائج المشروع عبارة عن رقعة أمان لنواة Linux تحاكي بت NX على معالجات x86 التي تفتقر إلى تطبيق NX أصلي في مكوناتها المادية. وعلى الرغم من أن مشروع Exec Shield قد تضمن العديد من المكونات الأخرى، إلا أن البعض يُشير إلى هذه الرقعة الأولى باسم Exec Shield.

تحاول رقعة Exec Shield الأولى تصنيف ذاكرة البيانات على أنها غير قابلة للتنفيذ وذاكرة البرنامج على أنها غير قابلة للكتابة. هذا يمنع العديد من الثغرات الأمنية ، مثل تلك الناجمة عن تجاوزات سعة المخزن المؤقت وغيرها من التقنيات التي تعتمد على الكتابة فوق البيانات وإدخال تعليمات برمجية في تلك البنى. كما توفر Exec Shield بعضًا من عشوائية تخطيط مساحة العناوين لدالة mmap () وقاعدة الكومة.

تزيد هذه الرقعة من صعوبة إدخال وتنفيذ الشيفرة الخبيثة ، مما يجعل معظم الثغرات الأمنية غير فعالة. لا يتطلب استخدام exec-shield إعادة تجميع التطبيقات بشكل كامل، على الرغم من أن بعض التطبيقات ( Mono ، Wine ، XEmacs ، Mplayer ) غير متوافقة تمامًا.

ومن الميزات الأخرى التي ظهرت من مشروع Exec Shield هي الملفات التنفيذية المستقلة عن الموضع (PIE)، وتصحيح عشوائية مساحة العنوان لنوى Linux، ومجموعة واسعة من فحوصات الأمان الداخلية لـ glibc التي تجعل استغلال الكومة وسلسلة التنسيق شبه مستحيل، وميزة GCC Fortify Source ، ونقل ودمج ميزة حماية مكدس GCC .

يعمل Exec Shield على جميع معالجات x86 باستخدام حدّ مقطع التعليمات البرمجية. وبفضل آلية عمله، يتميز Exec Shield بخفة وزنه؛ إلا أنه لا يوفر حماية كاملة لتخطيطات الذاكرة الافتراضية العشوائية . فإذا تم رفع حدّ مقطع التعليمات البرمجية، مثلاً باستدعاء الدالة mprotect() لجعل الذاكرة الأكبر قابلة للتنفيذ، فإن الحماية تُفقد عند تجاوز هذا الحد. وقد أشار إنجو مولنار إلى هذه النقطة في محادثة عبر البريد الإلكتروني. معظم التطبيقات تتعامل مع هذا الأمر بشكل سليم؛ إذ يبقى مكدس التعليمات البرمجية (الجزء المهم) أعلى من أي مكتبات مُرتبطة، وبالتالي لا يصبح قابلاً للتنفيذ إلا باستدعاءات صريحة من التطبيق.

حتى أغسطس 2004، لم تكن أي من مشاريع Exec Shield تسعى لفرض حماية الذاكرة بتقييد استخدام mprotect () على أي بنية؛ فمع أن الذاكرة قد لا تكون قابلة للتنفيذ في البداية، إلا أنها قد تصبح كذلك لاحقًا، لذا يسمح نظام التشغيل للتطبيق بتحديد صفحات الذاكرة على أنها قابلة للكتابة والتنفيذ في آنٍ واحد. مع ذلك، وبالتعاون مع مشروع Security-Enhanced Linux (SELinux)، تحظر السياسة القياسية لتوزيعة Fedora Core هذا السلوك لمعظم الملفات التنفيذية، باستثناءات قليلة لأسباب تتعلق بالتوافق.

تم تطوير Exec Shield بواسطة العديد من الأشخاص في Red Hat؛ تم إصدار أول تصحيح بواسطة Ingo Molnar من Red Hat وتم إصداره لأول مرة في مايو 2003. وهو جزء من Fedora Core 1 إلى 6 و Red Hat Enterprise Linux منذ الإصدار 3. ^{[ 1 ] [ 2 ]} ومن بين الأشخاص الآخرين الذين شاركوا في تطويره Jakub Jelínek و Ulrich Drepper و Richard Henderson و Arjan van de Ven.

علّق مولنار في عام 2007 على موقع LWN.net قائلاً: "وصلت أجزاء من [exec-shield] إلى المصدر الرئيسي، لكن جزءًا كبيرًا منها لم يصل". ^{[ 3 ]}

• بت NX
• أوبن وول
• ستاك جارد
• W^X

• صفحة ويب تصحيح Exec Shield الخاصة بـ Ingo Molnar، مؤرشفة بتاريخ 4 مارس 2016 على Wayback Machine ، وتتضمن وثائق في الملف ANNOUNCE-exec-shield، مؤرشفة بتاريخ 5 أغسطس 2004 على Wayback Machine.
• مقال مميز من نيوزفورج
• مقال مميز/مقال مشروع في مجلة ريد هات
• مشاكل أمنية سلبية تتعلق بـ ExecShield