Robertprast

تفشل عملية استيراد نقاط التحقق (checkpoint) الخاصة بـ CRI في التحقق من صحة مراجع الصور المحددة ضمن تكوين صورة نقطة التحقق. يمكن للمهاجم الذي يمتلك أذونات إنشاء البودات (pods) استخدام صورة نقطة تحقق مصممة خصيصًا لإجبار النظام على سحب صورة ضارة وتعيين علامة محلية عشوائية لها، مما يؤدي إلى تلويث ذاكرة التخزين المؤقتة المحلية للصورة في العقدة. وإذا استخدمت بودات أخرى على نفس العقدة العلامة الملوثة مع سياسة سحب `IfNotPresent` أو `Never`، فستقوم بتنفيذ الصورة الخبيثة بدلاً من الصورة الشرعية، مما يسمح للمهاجم بتنفيذ تعليمات برمجية تعسفية تحت هوية بود الضحية. بالإضافة إلى ذلك، قد تؤدي بعض المشكلات ذات الصلة إلى تنفيذ أوامر جذر المضيف أثناء الاستعادة.

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

يسمح خطأ في المكون الإضافي CRI باستعادة ملف `container.log` من صورة نقطة فحص دون التحقق من صحة مسار الارتباط الرمزي. قد يؤدي ذلك إلى قراءة ملف عشوائي على نظام المضيف عند استخدام `kubectl logs`.

يثق تطبيق CRI بشكل غير صحيح في تعليقات واجهة جهاز الحاوية (CDI) الموجودة ضمن بيانات تعريف صورة نقطة التحقق غير الموثوق بها أثناء استعادة الحاوية. بدلاً من الاعتماد حصريًّا على مواصفات وقت إنشاء البود (pod)، يحتفظ النظام بالتعليقات التوضيحية المتعلقة بـ CDI من أرشيف نقاط الفحص. وهذا يسمح للمستخدم الذي يمتلك أذونات إنشاء البود بتجاوز تخصيص موارد Kubernetes وفرض ملحقات الأجهزة عن طريق إدخال تعديلات CDI تعسفية، مثل عقد الأجهزة ووحدات التثبيت على المضيف، في الحاوية المستعادة. تتطلب هذه المشكلة تمكين CDI على العقدة ووجود مواصفات CDI مطابقة على المضيف للجهاز المطلوب.