قبل بضعة أيام تم إصدار الخبر تم الكشف عن التفاصيل نقطة ضعف تم العثور عليه في تنفيذ الآلية محدودية الموارد مجموعات cgroups v1 في Linux kernel المفهرس بالفعل تحت CVE-2022-0492.
وجدت هذه الثغرة الأمنيةيمكن استخدام البريد للخروج من الحاويات المعزولة ومن المفصل أن المشكلة كانت موجودة منذ Linux kernel 2.6.24.
في التدوينة ورد ذكر ذلك الثغرة الأمنية ناتجة عن خطأ منطقي في معالج ملف release_agent ، لذلك لم يتم إجراء الفحوصات المناسبة عند تشغيل برنامج التشغيل بأذونات كاملة.
الملف يتم استخدام release_agent لتعريف البرنامج الذي تنفذه النواة عندما تنتهي العملية في مجموعة cgroup. يعمل هذا البرنامج كجذر مع كل "القدرة" في مساحة اسم الجذر. كان من المفترض فقط أن يكون لدى المسؤول حق الوصول إلى تكوين release_agent ، ولكن في الواقع ، اقتصرت عمليات التحقق على منح حق الوصول إلى المستخدم الجذر ، والذي لم يمنع تغيير التكوين من الحاوية أو بواسطة مستخدم الجذر غير الإداري (CAP_SYS_ADMIN) .
سابقا، هذه الميزة لا تعتبر ثغرة أمنية، لكن الموقف تغير مع ظهور مساحات أسماء معرف المستخدم (مساحات أسماء المستخدمين) ، والتي تتيح لك إنشاء مستخدمين جذريين منفصلين في حاويات لا تتداخل مع المستخدم الجذر للبيئة الرئيسية.
وفقا لذلك، بالنسبة للهجوم ، فهذا يكفي في حاوية بها مستخدم جذر خاص بها في مساحة معرف مستخدم منفصلة لتوصيل معالج release_agent الخاص بك ، والذي بمجرد اكتمال العملية ، سيتم تشغيله بجميع امتيازات البيئة الأم.
بشكل افتراضي ، يتم تثبيت cgroupfs في حاوية للقراءة فقط ، ولكن لا توجد مشكلة في إعادة تثبيت هذه العناصر الزائفة في وضع الكتابة بحقوق CAP_SYS_ADMIN أو عن طريق إنشاء حاوية متداخلة مع مساحة اسم مستخدم منفصلة باستخدام استدعاء النظام لإيقاف المشاركة ، حيث تكون حقوق CAP_SYS_ADMIN متاحة للحاوية التي تم إنشاؤها.
الهجوم يمكن القيام به من خلال الحصول على امتيازات الجذر في حاوية معزولة أو عن طريق تشغيل الحاوية بدون علامة no_new_privs ، والتي تحظر الحصول على امتيازات إضافية.
يجب أن يدعم النظام مساحات الأسماء الممكنة مستخدم (يتم تمكينه افتراضيًا على Ubuntu و Fedora ، ولكن لم يتم تمكينه على Debian و RHEL) وله حق الوصول إلى مجموعة جذر v1 cgroup (على سبيل المثال ، يقوم Docker بتشغيل الحاويات في RDMA root cgroup). الهجوم ممكن أيضًا مع امتيازات CAP_SYS_ADMIN ، وفي هذه الحالة لا يلزم دعم مساحات أسماء المستخدمين والوصول إلى التسلسل الهرمي الجذر لـ cgroup v1.
بالإضافة إلى الخروج من الحاوية المعزولة ، تسمح الثغرة الأمنية أيضًا بالعمليات التي بدأها المستخدم الجذر بدون "قدرة" أو أي مستخدم لديه حقوق CAP_DAC_OVERRIDE (يتطلب الهجوم الوصول إلى الملف / sys / fs / cgroup / * / release_agent المملوك من قبل root) للوصول إلى كافة "إمكانات" النظام.
بصرف النظر عن الحاويات ، قد تسمح الثغرة الأمنية أيضًا بعمليات مضيف الجذر بدون إمكانات ، أو عمليات مضيف غير جذرية مع إمكانية CAP_DAC_OVERRIDE ، لتصعيد الامتيازات إلى الإمكانات الكاملة. قد يسمح هذا للمهاجمين بتجاوز إجراء تقوية تستخدمه خدمات معينة ، والذي يزيل القدرات في محاولة للحد من التأثير في حالة حدوث حل وسط.
توصي الوحدة 42 المستخدمين بالترقية إلى إصدار ثابت من النواة. لأولئك الذين يشغلون الحاويات ، قم بتمكين Seccomp وتأكد من تمكين AppArmor أو SELinux. يمكن لمستخدمي Prisma Cloud الرجوع إلى قسم "حماية سحابة Prisma" للاطلاع على عوامل التخفيف التي توفرها Prisma Cloud.
لاحظ أنه لا يمكن استغلال الثغرة الأمنية عند استخدام آليات حماية Seccomp أو AppArmor أو SELinux لعزل إضافي للحاويات ، حيث يحظر Seccomp استدعاء نظام unshare () ولا يسمح AppArmor و SELinux بتثبيت cgroupfs في وضع الكتابة.
أخيرًا ، الجدير بالذكر أنه تم إصلاحه في إصدارات kernel 5.16.12 و 5.15.26 و 5.10.97 و 5.4.177 و 4.19.229 و 4.14.266 و 4.9.301. يمكنك متابعة إصدار تحديثات الحزمة في التوزيعات على هذه الصفحات: ديبيان, SUSE, أوبونتو, RHEL, فيدورا, جنتو, قوس لينكس.
أخيرا إذا كنت مهتمًا بمعرفة المزيد عنها، يمكنك التحقق من التفاصيل في الرابط التالي.