ملاحظة perev. : الليلة الماضية ، أخبر Aleksa Sarai ، وهو مهندس حاويات رئيسي في SUSE Linux ، القائمة البريدية الخاصة بالثغرات الأمنية الخاصة بالثغرات الأمنية الحساسة التي قد تؤدي إلى runc / LXC والتي قد تسمح للمهاجمين بالوصول إلى حاوية معزولة للحصول على امتيازات الجذر في النظام المضيف. نظرًا لأنه تم تحديد المشكلة في التطبيق المرجعي لوقت تشغيل الحاوية - runc - فهي تؤثر على العديد من أنظمة الحاويات بما في ذلك Docker / Moby و Podman و cri-o (و Kubernetes نفسها). ترد التفاصيل أدناه في شكل ترجمة رسالة المهندس إلى قائمة بريدية.أنا واحد من مشغلي runc (وقت تشغيل الحاوية الأساسي الذي تستخدمه Docker ، cri-o ، containerd ، Kubernetes ، إلخ). في الآونة الأخيرة ، أصبح معروفًا بوجود ثغرة أمنية قمنا بفحصها وتصحيحها.
الباحثون الذين اكتشفوا الضعف:
- آدم إيانيوك ؛
- بوريس بوبلاوسكي.
بالإضافة إلى ذلك ، اكتشف Aleksa Sarai (أي ، I) أن LXC يتأثر أيضًا بنسخة أكثر تطوراً من هذه الثغرة الأمنية.
مراجعة قصيرة
تسمح مشكلة عدم الحصانة لحاوية ضارة (مع الحد الأدنى من تفاعل المستخدم) بالكتابة فوق مضيف runc الثنائي وبالتالي تكون قادرة على تنفيذ التعليمات البرمجية مع امتيازات الجذر على المضيف. درجة تفاعل المستخدم لدرجة تسمح لك بتشغيل أي أوامر (لا يهم إذا كان المهاجم يتحكم في الأمر) بامتيازات الجذر داخل الحاوية في أي من هذه السياقات:
- إنشاء حاوية جديدة من صورة يتحكم فيها المهاجم ؛
- الاتصال (
docker exec ) بحاوية موجودة سبق للمهاجم الوصول إليها من خلال الكتابة.
لا يتم
حظر مشكلة
عدم الحصانة هذه إما من خلال سياسة AppArmor الافتراضية أو سياسة SELinux الافتراضية في Fedora * (لأن عمليات الحاوية تبدو وكأنها بدأت مع
container_runtime_t ). ومع ذلك ، يتم
حظره عن طريق الاستخدام الصحيح لمساحات أسماء المستخدمين (حيث لا يتم تعيين جذر المضيف إلى مساحة اسم المستخدم للحاوية).
ناقل CVSSv3 (مع تصنيف 7.2) هو كما يلي:
AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:Hتم تعيين
المشكلة CVE-2019-5736 .
* المشكلة تنطبق فقط على حزمة moby-engine في Fedora. حزمة docker ، مثل podman ، محمية من التشغيل ، حيث تبدأ عمليات container_t .بقع
أقوم بتطبيق التصحيح المناسب لإصلاح المشكلة (
0001-nsenter-clone-proc-self-exe-to-avoid-exposing-host-b.patch ). يعتمد هذا على فرع
HEAD ، على الرغم من أن التعليمة البرمجية الموجودة في
libcontainer/nsenter/ تتغير نادرًا بحيث يتم تطبيق التصحيح على الأرجح على أي إصدار قديم تقريبًا من قاعدة كود runc التي تتعامل معها.
يرجى ملاحظة أن
التصحيح الذي أدفعه إلى فرع runc الرئيسي هو نسخة معدلة من هذا التصحيح ، على الرغم من أنها متطابقة وظيفيا (إذا لم تقم بتصحيح ملفاتك باستخدام التصحيح المرفق حتى الآن ، فإننا نوصي باستخدام الإصدار الأساسي).
قانون استغلال الثانوية
طلب بعض البائعين رمز استغلال للتأكد من أن التصحيحات قد حلت المشكلة. نظرًا لأن المشكلة خطيرة للغاية (خاصة بالنسبة للبائعين في السحابة العامة) ، فقد قررنا تقديم مثل هذا الرمز. يعد الاستغلال الذي كتبته أكثر عمومية من الشفرة الأصلية التي قدمها الباحثون ويعمل لصالح LXC (لا يتطلب الأمر تعديلات قوية لتتمكن من تطبيقها على بيئات تنفيذية أخرى معرضة للتأثر). يتم توفير تفاصيل حول كيفية استخدام رمز استغلال في
README .
وفقًا لقواعد OpenWall ، سيتم إطلاق رمز الاستغلال
علنًا بعد 7 أيام من اتفاقية حقوق الأشخاص ذوي الإعاقة (أي ، 18 فبراير 2019).
إذا كان لديك وقت تشغيل الحاوية ، فالرجاء التأكد من عدم تأثرها بهذه الثغرة الأمنية.التأثير على المشاريع الأخرى
تجدر الإشارة إلى أنه أثناء إجراء مزيد من التحقيق في المشكلة ، وجدت أن LXC لديه ثغرة أمنية مماثلة ، وقد قاموا بالفعل بإلغاء
تصحيح مماثل لتطورنا المشترك. LXC أكثر صعوبة في العمل ، لكن المشكلة نفسها هي نفسها.
أدت مناقشة مع ممثلي systemd-nspawn إلى استنتاج أنهم غير معرضين للخطر (نظرًا لأن لديهم طريقة مختلفة للاتصال بالحاوية لـ LXC و runc).
اتصل بي ممثلو Apache Mesos أيضًا ، وأبلغوا أنهم معرضون أيضًا للخطر (أعتقد أنهم استخدموا ببساطة رمز الاستغلال الذي سيتم نشره). من المحتمل جدًا أن تكون معظم أوقات تشغيل الحاويات معرضة للخطر إذا لم تكن قد اتخذت من قبل خطوات غير معتادة لتخفيف تأثيرها المحتمل.
اخبار اخرى
لقد أنشأنا رسالة إخبارية لثغرات أمنية مستقبلية: يتم وصف عملية الانضمام إليها
هنا (تعتمد على قائمة المراسلات الأمنية لإعلان Kubernetes). يرجى الانضمام إذا قمت بتوزيع أي وقت تشغيل للحاويات التي تعتمد على runc (أو مشاريع OCI الأخرى).
PS من المترجم
مشكلة CVE-2019-5736 في متتبعات توزيعات Linux الشائعة:
...
ومنشور مدونة Kubernetes (راجع قسم "ماذا علي أن أفعل؟").