إذا تم استغلالها ، يمكن أن تسمح هذه العيوب للمهاجمين بالوصول غير المصرح به إلى المعلومات الحساسة أو التسبب بشكل عام في حدوث مشكلات
مؤخرا ظهرت أخبار داكتشاف نقاط ضعف جديدة في runC (أداة CLI لبناء وتشغيل الحاويات على Linux) CVE-2024-21626 وفي BuildKit (CVE-2024-23651، وCVE-2024-23652، وCVE-2024-23653)، واحدة من أعظم المخاوف CVE-2024-21626، لأنها تمثل ثغرة أمنية خطيرة تسمح بالوصول إلى نظام الملفات الخاص بنظام التشغيل المضيف.
CVE-2024-21626 يسمح بالوصول إلى نظام ملفات البيئة المضيفة من حاوية معزولة. أثناء الهجوم، يمكن للمهاجم الكتابة فوق بعض الملفات القابلة للتنفيذ في البيئة المضيفة وتنفيذ التعليمات البرمجية الخاصة به خارج الحاوية.
وهذا أمر مثير للقلق بشكل خاص في بيئات مثل Kubernetes، حيث تعمل الحاويات على العقد المشتركة. من خلال استغلال هذه الثغرة الأمنية، يمكن للمهاجم الحصول على تحكم مميز في المضيف، مما قد يمنح وصولاً غير مصرح به إلى البودات الأخرى وبيانات الآخرين على نفس العقدة.
علاوة على ذلك، فإن هذه الثغرة الأمنية يؤثر أيضًا على عمليات البناء التي يتم تشغيلها في بيئات الحاويةمما يمنح المهاجمين الفرصة لتأسيس موطئ قدم ضمن عملية البناء. هذا السيناريو يمكن أن يؤدي إلى حصول المهاجم على بيانات اعتماد مرتفعة، والتي من شأنها أن تمنحك الوصول إلى أعباء عمل الإنتاج الهامة أو البيئات الحساسة الأخرى. في جوهره، يمتد التأثير إلى ما هو أبعد من مجرد تسريب المعلومات أو تنفيذ تعليمات برمجية عشوائية، ويمكن أن يعرض سلامة وأمن بيئة التطوير والإنتاج بأكملها للخطر.
في البيئات التي يتم فيها استخدام Docker أو Kubernetes، يمكن تنفيذ الهجوم باستخدام صورة حاوية مصممة خصيصًا. بمجرد تثبيت هذه الصورة وتشغيلها، يمكن للمهاجم الوصول إلى نظام ملفات خارجي من الحاوية. في حالة Docker، من الممكن العمل من خلال ملف Dockerfile المصمم خصيصًا. يمكن أيضًا استغلال الثغرة الأمنية في حالة بدء العمليات في حاوية باستخدام الأمر "runc exec" وربط دليل العمل بمساحة اسم البيئة المضيفة.
المشكلة الرئيسية هي تسرب واصف الملف وأثناء القيام بـ O_CLOEXEC كافة واصفات الملف قبل تنفيذ رمز الحاوية، الملف يكون الواصف مفتوحًا عند القيام بـ setcwd(2)، مما يعني أن المرجع يمكن أن تظل حية في الحاوية عن طريق ضبط وضع العمل الدليل كمسار يتم حله من خلال واصف الملف (yeلم يتم تعيين البت غير القابل للتفريغ بعد execve(2)، مما يعني وجوده طرق متعددة لمهاجمة هذا إلى جانب التكوينات السيئة).
يكمن سبب الثغرة الأمنية في تسرب واصفات الملفات الداخلية. قبل تنفيذ التعليمات البرمجية داخل الحاوية، يقوم runc بإغلاق جميع واصفات الملفات باستخدام علامة O_CLOEXEC. ومع ذلك، فإن عمليات التنفيذ اللاحقة لـ setcwd() تترك واصف ملف مفتوحًا يشير إلى دليل العمل ويظل قابلاً للوصول بعد بدء تشغيل الحاوية. تم اقتراح عدة سيناريوهات أساسية لمهاجمة البيئة المضيفة باستخدام واصف الملف المتبقي.
يذكر أن مثال على استغلال الثغرة الأمنية إذا تم تكوين حاوية:
لتعيين Process.cwd على /proc/self/fd/7/، سيكون لعملية pid1 الناتجة دليل عمل في مساحة اسم التحميل الخاصة بالمضيف، وبالتالي ستكون العملية الناتجة قادرة على الوصول إلى ملفات System.host بأكملها. هذا وحده ليس استغلالًا ضد runc. يمكن للمهاجم أيضًا خداع المستخدم لتشغيل صورة حاوية ضارة، مما يسمح لعملية الحاوية بالوصول إلى نظام الملفات المضيف عبر runc. يمكن أن يمتد هذا إلى الكتابة فوق الثنائيات المضيفة، مما يؤدي إلى الهروب الكامل للحاوية.
أخيرًا ، يجب ذكر ذلك تم إصلاح الثغرة الأمنية في إصدار runc 1.1.12لذا فإن التوصية هي التحديث إلى الإصدار الجديد. إذا كنت مهتمًا بمعرفة المزيد عنه، يمكنك الرجوع إلى التفاصيل في الرابط التالي.