يتضمن Glibc إصلاحًا لثغرة memcpy التي أعدها مطورو نظام التشغيل Aurora

شارك مطورو نظام تشغيل الهاتف المحمول Aurora (وهو شوكة من نظام Sailfish OS الذي طورته شركة Open Mobile Platform) قصة كاشفة حول القضاء على الضعف الحرج (CVE-2020-6096) في Glibc، والذي يظهر فقط على منصة ARMv7. تم الكشف عن معلومات حول الثغرة الأمنية في شهر مايو الماضي، ولكن حتى الأيام الأخيرة، لم تكن الإصلاحات متاحة، على الرغم من أن الثغرات الأمنية مُكَلَّف مستوى عالٍ من الخطر ويوجد نموذج أولي عملي لاستغلال يسمح لك بتنظيم تنفيذ التعليمات البرمجية عند معالجة البيانات المنسقة بطريقة معينة في وظائف memcpy() وmemmove(). إصلاحات الحزمة ل ديبيان и أوبونتو لم يتم إصدارها بعد وتبقى الثغرة الأمنية دون إصلاح لمدة شهرين تقريبًا من لحظة الكشف عنها للعامة وخمسة أشهر من لحظة إخطار مطوري Glibc.

تجلت الثغرة الأمنية في تنفيذ memcpy() و memmove() في لغة التجميع لـ ARMv7 وكان سببها معالجة غير صحيحة للقيم السالبة للمعلمة التي تحدد حجم المنطقة المنسوخة. بدأت مشاكل تطوير التصحيح عندما بدأت الشركات SUSE и ريد هات أعلنت أن منصاتها لم تتأثر بالمشكلة، لأنها لا تعمل على أنظمة 32 بت ARMv7، ولم تشارك في إنشاء الإصلاح. يبدو أن مطوري العديد من التوزيعات المضمنة اعتمدوا على فريق Glibc، ولم يشاركوا أيضًا بشكل فعال في إعداد الإصلاح.

خيار رقعة ولمنع المشكلة، اقترحت شركة هواوي على الفور تقريبًا أنها حاولت استبدال تعليمات التجميع التي تعمل بالمعاملات الموقعة (bge وblt) بنظائرها غير الموقعة (blo وbhs). قام مشرفو Glibc بتطوير مجموعة من الاختبارات للتحقق من حالات الخطأ المختلفة، وبعد ذلك اتضح أن تصحيح Huawei لم يكن مناسبًا ولم يعالج جميع المجموعات الممكنة من بيانات الإدخال.

نظرًا لأن نظام التشغيل Aurora لديه إصدار 32 بت لـ ARM، فقد قرر مطوروه إغلاق الثغرة الأمنية بأنفسهم وتقديم حل للمجتمع. كانت الصعوبة هي أنه كان من الضروري كتابة تنفيذ فعال للغة التجميع للوظيفة ومراعاة الخيارات المختلفة لوسائط الإدخال. تمت إعادة كتابة التنفيذ باستخدام تعليمات غير موقعة. رقعة اتضح أنها صغيرة، ولكن المشكلة الرئيسية كانت الحفاظ على سرعة التنفيذ وتجنب تدهور أداء وظائف memcpy وmemmove، مع الحفاظ على التوافق مع جميع مجموعات قيم الإدخال.

في بداية شهر يونيو، تم إعداد نسختين من الإصلاح، بعد اجتياز إطار اختبار مشرفي Glibc ومجموعة الاختبار الداخلي لـ Aurora. في 3 يونيو، تم اختيار أحد الخيارات و أرسلت إلى القائمة البريدية Glibc. بعد إسبوع
كان مقترح تصحيح آخر مشابه في النهج، والذي صحح مشكلة في تطبيق multiarch، والتي حاولت Huawei سابقًا إصلاحها. استغرق الاختبار شهرًا و التسجيل القانوني نظرا لأهمية التصحيح.
تصحيحات 8 يوليو تم قبولها إلى الفرع الرئيسي لإصدار glibc 2.32 القادم. يتضمن التنفيذ رقعتين - الأول لتنفيذ memcpy متعدد الأركان لـ ARMv7 و ثان لتطبيق لغة التجميع العامة memcpy() و memmove() لـ ARM.

تؤثر المشكلة على الملايين من أجهزة ARMv7 التي تعمل بنظام التشغيل Linux، وبدون التحديث المناسب، يتعرض المالكون للخطر عند توصيلهم بالشبكة (يمكن مهاجمة الخدمات والتطبيقات التي يمكن الوصول إليها عبر الشبكة والتي تقبل بيانات الإدخال دون قيود الحجم). على سبيل المثال، تُظهر الثغرة التي أعدها الباحثون الذين حددوا الثغرة الأمنية كيفية مهاجمة خادم HTTP المدمج في نظام معلومات السيارة عن طريق إرسال طلب GET كبير جدًا والحصول على حق الوصول الجذري إلى النظام.

المصدر: opennet.ru

إضافة تعليق