يدعو Kees Cook إلى تنظيم عمل أفضل على Linux فيما يتعلق بإصلاحات الأخطاء

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

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

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

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

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

ومما زاد الطين بلة ، أن العديد من إصلاحات الثغرات الأمنية المحتملة لا يتم تمييزها بمعرفات CVE أو لا تتلقى معرف CVE بعد فترة من إصدار التصحيح.

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

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

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

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

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

مصدر: https://security.googleblog.com


اترك تعليقك

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها ب *

*

*

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