قبل أيام قليلة ، أفرج عن الأنباء أن فريق التحقيق اكتشفت Qualys رفضًا للثغرة الأمنية بسبب استنفاد المكدس في systemd ، لذلك يمكن لأي مستخدم غير متميز استغلال هذه الثغرة الأمنية لحظر النظام د.
عالي التأثر تم فهرستها بالفعل كـ (CVE-2021-33910) يذكر أنه يؤثر على systemd بسبب فشل عند محاولة تحميل دليل بحجم مسار أكبر من 8 ميجابايت من خلال FUSE وفيه تنفد عملية تهيئة التحكم (PID1) من ذاكرة المكدس ويتم قفلها ، مما يؤدي إلى النظام في حالة "ذعر".
تم تقديم هذه الثغرة الأمنية في systemd v220 (أبريل 2015) من خلال الالتزام 7410616c ("kernel: إعادة صياغة اسم الوحدة ومنطق التحقق من الصحة") ، والذي استبدل strdup () على الكومة بـ strdupa () في البطارية. يتيح الاستغلال الناجح لهذه الثغرة الأمنية لأي مستخدم غير متمتع التسبب في رفض الخدمة من خلال ذعر kernel.
بمجرد أن أكد فريق أبحاث Qualys الثغرة الأمنية ، شاركت Qualys في الكشف المسؤول عن الثغرة ونسقت مع المؤلف وتوزيعات المصادر المفتوحة للإعلان عن الثغرة الأمنية.
يذكر الباحثون ذلك المشكلة المتعلقة بـ CVE-2021-33910 بسبب حقيقة أن يراقب systemd ويحلل محتوى / proc / self / mountinfo ويتعامل مع كل نقطة تحميل في دالة unit_name_path_escape () التي تؤدي إلى تنفيذ عملية تسمى "strdupa ()" والتي تهتم بتخصيص البيانات على المكدس بدلاً من الكومة.
هذا هو السبب منذ ذلك الحين الحد الأقصى لحجم المكدس المسموح به محدود بواسطة وظيفة "RLIMIT_STACK" ، يؤدي التعامل مع مسار طويل جدًا إلى نقطة التحميل إلى تعليق عملية "PID1" مما يؤدي إلى توقف النظام.
بالإضافة إلى ذلك ، ذكروا أنه لكي يكون الهجوم وظيفيًا ، يمكن استخدام أبسط وحدة FUSE جنبًا إلى جنب مع استخدام دليل متداخل للغاية كنقطة تحميل ، يتجاوز حجم مسارها 8 ميجا بايت.
أيضا من المهم أن نذكر أن الباحثين كواليس ذكر حالة معينة مع الضعف ، منذ ذلك الحين خاصة مع الإصدار 248 من systemd ، فإن الاستغلال لا يعمل بسبب خطأ موجود في كود النظام الذي يتسبب في فشل / proc / self / mountinfo. من المثير للاهتمام أيضًا ظهور موقف مشابه جدًا في عام 2018 ، أثناء محاولة كتابة ثغرة أمنية CVE-2018-14634 في نواة Linux ، حيث وجد باحثو Qualys ثلاثة ثغرات أمنية أخرى في systemd.
حول الضعف ذكر فريق ريد هات من المحتمل أيضًا أن يتأثر أي منتج متوافق مع RHEL.
وهذا يشمل:
- حاويات المنتج التي تستند إلى صور حاوية RHEL أو UBI. يتم تحديث هذه الصور بانتظام ، ويمكن عرض حالة الحاوية التي تشير إلى ما إذا كان هناك إصلاح متاح لهذا الخلل في مؤشر صحة الحاوية ، وهو جزء من كتالوج Red Hat Container (https://access.redhat.com/containers) .
- المنتجات التي تسحب الحزم من قناة RHEL. تأكد من تحديث حزمة Red Hat Enterprise Linux systemd الأساسية في بيئات المنتج هذه.
نظرًا لاتساع مساحة الهجوم لهذه الثغرة الأمنية، توصي Qualys المستخدمين بتطبيق التصحيحات المناسبة (التي تم إصدارها بالفعل قبل بضعة أيام) لهذه الثغرة الأمنية على الفور.
كما ذكرنا سابقًا ، ظهرت المشكلة منذ systemd 220 (أبريل 2015) و تم إصلاحه بالفعل في المستودع الرئيسي لـ systemd وتم إصلاحه في معظم التوزيعات Linux main وكذلك مشتقاته يمكنك التحقق من الحالة في الروابط التالية (ديبيان, أوبونتو, فيدورا, RHEL، SUSE ، قوس).
وأخيرا، إذا كنت مهتمًا بمعرفة المزيد عنها حول هذه الثغرة الأمنية ، يمكنك التحقق من تفاصيلها في الرابط التالي.