اقترحت Checkpoint تقنية حماية الارتباط الآمن، مما يزيد من صعوبة استغلال نقاط الضعف

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

تم إعداد تصحيحات تنفيذ الارتباط الآمن لـ Glibc (ptmalloc)، وuClibc-NG (dlmalloc)، وgperftools (tcmalloc)، وGoogle TCMalloc، كما تم اقتراحها أيضًا لترقية الحماية في Chromium (في
منذ عام 2012، قام Chromium بالفعل ببناء تقنية الحماية MaskPtr التي تهدف إلى حل نفس المشكلة، ولكن الحل من Checkpoint يوضح أداءً أعلى).
تمت الموافقة بالفعل على تسليم التصحيحات المقترحة في إصدار أغسطس Glibc 3.32 وسيتم تمكين الارتباط الآمن افتراضيًا. يدعم uClibc-NG الارتباط الآمن دخلت تم تضمينه في الإصدار 1.0.33 ويتم تمكينه افتراضيًا. التغييرات في gperftools (tcmalloc القديم) وافقت، ولكن سيتم تقديمه كخيار في إصدار مستقبلي.

المطورين TCMaloc (جديد tcmalloc) رفض القبول تغيير، مشيرًا إلى التدهور الشديد في الأداء والحاجة إلى إضافة اختبارات مكثفة للتحقق بانتظام من أن كل شيء يعمل كما هو متوقع. أظهر الاختبار الذي أجراه مهندسو Checkpoint أن طريقة الارتباط الآمن لا تؤدي إلى استهلاك إضافي للذاكرة، وأن الأداء عند إجراء عمليات الكومة ينخفض ​​في المتوسط ​​بنسبة 0.02% فقط، وفي أسوأ السيناريوهات بنسبة 1.5% (للمقارنة، الحمل الزائد في الطريقة المستخدمة في Chromium تقدر بـ "أقل من 2٪"). تضمين
يؤدي الارتباط الآمن إلى تنفيذ 2-3 تعليمات تجميع إضافية في كل مرة يتم فيها استدعاء free()، و3-4 تعليمات في كل مرة يتم فيها استدعاء malloc(). ليس من الضروري تشغيل مراحل التهيئة وتوليد القيمة العشوائية.

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

+#تعريف PROTECT_PTR(pos, ptr) \
+ ((__typeof (ptr)) ((((size_t) pos) >> 12) ^ ((size_t) ptr)))

+#تعريف REVEAL_PTR(ptr) PROTECT_PTR (&ptr, ptr)

- nextp = p->fd;
+ nextp = REVEAL_PTR (p->fd);
...

جوهر هذه الطريقة هو استخدام البيانات العشوائية من آلية التوزيع العشوائي لعناوين ASLR (mmap_base) لحماية القوائم المرتبطة بشكل فردي مثل Fast-Bins وTCache. قبل أن يتم تطبيق القيمة على مؤشر للعنصر التالي في القائمة، فإنها تنفذ تحويل قناع وتتحقق من محاذاة الصفحة. يتم استبدال المؤشر بنتيجة العملية "(L >> PAGE_SHIFT) XOR (P)"، حيث P هي قيمة المؤشر وL هو موقع الذاكرة حيث يتم تخزين المؤشر.

عندما تستخدم في النظام ASLR (التوزيع العشوائي لتخطيط مساحة العنوان) يحتوي جزء من بتات L مع عنوان قاعدة الكومة على قيم عشوائية تُستخدم كمفتاح لتشفير P (يتم استخراجها بواسطة عملية إزاحة 12 بت لصفحات 4096 بايت). يقلل هذا التلاعب من خطر اختطاف المؤشر في إحدى برمجيات إكسبلويت، حيث لا يتم تخزين المؤشر في شكله الأصلي ويتطلب استبداله معرفة تخصيص الكومة. بالإضافة إلى ذلك، يحتوي رمز التصحيح أيضًا على فحص إضافي لمحاذاة الكتلة، والذي لا يسمح للمهاجم باستبدال المؤشر بقيمة غير محاذاة ويتطلب معرفة عدد البتات التي تمت محاذاتها، والتي تسمح أيضًا بالحظر في أنظمة 64 بت 15 من أصل 16 محاولة هجوم لا تأخذ في الاعتبار الاصطفاف

تعتبر هذه الطريقة فعالة للحماية من الهجمات التي تستخدم إعادة كتابة المؤشر جزئيًا (تغيير وحدات البايت المنخفضة)، وإعادة كتابة المؤشر بالكامل (إعادة التوجيه إلى رمز المهاجم) وتغيير موضع القائمة في عنوان غير محاذى. على سبيل المثال، تبين أن استخدام Safe-Linking في malloc من شأنه أن يسمح بحظر الاستغلال مؤخرًا تم تحديدها من قبل نفس الباحثين الضعف CVE-2020-6007 في الضوء الذكي Philips Hue Bridge، الناتج عن تجاوز سعة المخزن المؤقت والسماح لك بالتحكم في الجهاز.

المصدر: opennet.ru