كشفت تفاصيل عن التصحيحات المقدمة من جامعة مينيسوتا

خلال الأيام القليلة الماضية قضية على الإجراءات التي اتخذتها مجموعة من الباحثين من جامعة مينيسوتانظرًا لأنه من وجهة نظر الكثيرين ، فإن مثل هذه الإجراءات المتعلقة بإدخال الثغرات الأمنية في Linux Kernel ليس لها أي مبرر.

وعلى الرغم من وجود مجموعة باحثو جامعة مينيسوتلنشر خطاب اعتذار مفتوح ، الذي تم حظر قبول التغييرات التي تم إجراؤها على Linux kernel بواسطة كشف جريج كروه هارتمان عن التفاصيل من التصحيحات المرسلة إلى مطوري kernel والمراسلات مع المشرفين المرتبطين بهذه التصحيحات.

من الجدير بالذكر أن تم رفض كافة تصحيحات المشكلة بمبادرة من المشرفين ، لم تتم الموافقة على أي من التصحيحات. توضح هذه الحقيقة سبب تصرف Greg Kroah-Hartman بهذه القسوة ، حيث إنه من غير الواضح ما الذي كان سيفعله الباحثون إذا تمت الموافقة على التصحيحات من قبل المشرف.

في وقت لاحق، جادلوا بأنهم يعتزمون الإبلاغ عن الخطأ ولن يسمحوا للبقع بالانتقال إلى Git ، لكن من غير الواضح ما الذي سيفعلونه بالفعل أو إلى أي مدى يمكن أن يذهبوا.

في المجموع ، في أغسطس 2020 ، تم إرسال خمس تصحيحات من العناوين المجهولة acostag.ubuntu@gmail.com و jameslouisebond@gmail.com (رسالة من جيمس بوند): اثنان صحيحان وثلاثة تتضمن أخطاء خفية ، مما خلق ظروفًا لظهور نقاط الضعف.

كل رقعة تحتوي على 1 إلى 4 أسطر فقط من التعليمات البرمجية. كانت الفكرة الرئيسية وراء التصحيحات السيئة هي أن إصلاح تسرب الذاكرة يمكن أن يخلق حالة من الضعف الحر المزدوج.

يهدف المشروع إلى تحسين أمن عملية الترقيع في OSS. كجزء من المشروع ، نقوم بدراسة المشاكل المحتملة في عملية الترقيع OSS ، بما في ذلك أسباب المشاكل والاقتراحات لمعالجتها.

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

بناءً على هذه التصحيحات ، نلخص أنماطها ، وندرس الأسباب المحددة التي تجعل من الصعب اكتشاف بقع إدخال الأخطاء (مع التحليل النوعي والكمي) ، والأهم من ذلك ، تقديم اقتراحات لمعالجة المشكلة.

أصلح التصحيح الإشكالي الأول تسرب الذاكرة عن طريق إضافة استدعاء إلى kfree () قبل إعادة التحكم في حالة حدوث خطأ ، ولكن تهيئة الظروف للوصول إلى منطقة الذاكرة بعد تحريرها (استخدام بعد خالي).

تم رفض التصحيح المحدد من قبل المشرف، الذي حدد المشكلة وأشار إلى أنه منذ عام مضى ، حاول شخص ما بالفعل اقتراح تغيير مماثل وتم قبوله في البداية ، لكنه تجاهل في نفس اليوم بعد تحديد ظروف الضعف.

يحتوي التصحيح الثاني أيضًا على شروط لمشكلة التآكل بعد الإصدار. لم يتم قبول التصحيح المحدد من قبل المشرف ، الذي رفض التصحيح بسبب مشكلة أخرى في list_add_tail ، لكنه لم يلاحظ أنه يمكن تحرير مؤشر "chdev" في وظيفة put_device ، والتي يتم استخدامها بعد ذلك في استدعاء dev_err (& chdev -> ديف ..). ومع ذلك ، لم يتم قبول التصحيح ، وإن كان ذلك لأسباب لا علاقة لها بالضعف.

ومن المثير للاهتمام، في البداية كان من المفترض أن 4 من أصل 5 تصحيحات بها مشاكل ، لكن الباحثين أنفسهم ارتكبوا خطأ وفي رقعة إشكالية ، في رأيهم ، تم اقتراح الحل الصحيح ، دون الشروط المفترضة لاستخدام الذاكرة بعد الإطلاق.

في هذا العمل ، نقدم مفهوم "الضعف غير الناضج" حيث تكون حالة الضعف مفقودة ، لكنها يمكن أن تصبح حالة حقيقية عندما تكون الحالة غير ناضجة.
قدمها التصحيح لخلل آخر.

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

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

تم رفض التصحيح الثالث أيضًا من قبل المشرف بسبب خطأ آخر بدون ثغرة أمنية (تطبيق مزدوج في pdev).


محتوى المقال يلتزم بمبادئنا أخلاقيات التحرير. للإبلاغ عن خطأ انقر فوق هنا.

كن أول من يعلق

اترك تعليقك

لن يتم نشر عنوان بريدك الإلكتروني.

*

*

  1. المسؤول عن البيانات: ميغيل أنخيل جاتون
  2. الغرض من البيانات: التحكم في الرسائل الاقتحامية ، وإدارة التعليقات.
  3. الشرعية: موافقتك
  4. توصيل البيانات: لن يتم إرسال البيانات إلى أطراف ثالثة إلا بموجب التزام قانوني.
  5. تخزين البيانات: قاعدة البيانات التي تستضيفها شركة Occentus Networks (الاتحاد الأوروبي)
  6. الحقوق: يمكنك في أي وقت تقييد معلوماتك واستعادتها وحذفها.