اكتشفت Wiz Research ثغرة أمنية خطيرة في الهروب من الحاوية في NVIDIA Container Toolkit (NCT)، والتي أطلقنا عليها اسم #نفيدياسكيب. تعمل مجموعة الأدوات هذه على تشغيل العديد من خدمات الذكاء الاصطناعي التي يقدمها موفرو الخدمات السحابية وSaaS، ويتم الآن تتبع الثغرة الأمنية على أنها CVE-2025-23266، تم تعيين أ درجة CVSS 9.0 (حرجة). فهو يسمح للحاوية الضارة بتجاوز إجراءات العزل والحصول على وصول كامل للجذر إلى الجهاز المضيف. ينبع هذا الخلل من تكوين خاطئ دقيق في كيفية تعامل مجموعة الأدوات مع خطافات OCI، ويمكن استغلاله بطريقة بسيطة بشكل مذهل ملف Dockerfile ذو ثلاثة أسطر.
ونظرًا لأن مجموعة أدوات NVIDIA Container Toolkit هي العمود الفقري للعديد من خدمات الذكاء الاصطناعي ووحدة معالجة الرسومات المُدارة عبر جميع موفري الخدمات السحابية الرئيسيين، فإن هذه الثغرة الأمنية تمثل خطرًا نظاميًا على النظام البيئي للذكاء الاصطناعي، مما قد يسمح للمهاجمين بهدم الجدران التي تفصل بين العملاء المختلفين، مما يؤثر على آلاف المؤسسات.
خطر هذه الثغرة الأمنية هو الأكثر حدة في الخدمات السحابية المُدارة بالذكاء الاصطناعي التي تسمح للعملاء بتشغيل حاويات الذكاء الاصطناعي الخاصة بهم على البنية التحتية المشتركة لوحدة معالجة الرسومات. في هذا السيناريو، يمكن للعميل الخبيث استخدام هذه الثغرة الأمنية لتشغيل حاوية مصممة خصيصًا، والهروب من الحدود المقصودة، وتحقيق التحكم الجذري الكامل في الجهاز المضيف. من هناك، يمكن للمهاجم الوصول إلى البيانات الحساسة ونماذج الملكية الخاصة بجميع العملاء الآخرين أو سرقتها أو معالجتها يعمل على نفس الأجهزة المشتركة.
هذه هي بالضبط فئة الثغرات الأمنية التي أثبتت أنها تمثل خطرًا نظاميًا عبر سحابة الذكاء الاصطناعي. قبل بضعة أشهر، أظهرت شركة Wiz Research كيف سمحت عيوب هروب الحاويات المماثلة بالوصول إلى بيانات العملاء الحساسة في الخدمات الرئيسية مثل Replicate وDigitalOcean. إن تكرار هذه القضايا الأساسية يسلط الضوء على الحاجة الملحة إلى التدقيق في أمن البنية التحتية الأساسية للذكاء الاصطناعي لدينا بينما يتسابق العالم لتبنيها.
المكونات المتضررة:
-
مجموعة أدوات حاوية NVIDIA: جميع الإصدارات حتى الإصدار 1.17.7 (وضع CDI فقط للإصدارات السابقة للإصدار 1.17.5)
-
NVIDIA GPU Operator: جميع الإصدارات حتى الإصدار 25.3.1 ويتضمن ذلك
التوصية الأساسية هي أن الترقية إلى أحدث إصدار من مجموعة أدوات حاوية NVIDIA كما نصحت في نشرة الأمن NVIDIA.
يمكن لعملاء Wiz استخدام هذا الاستعلام المضمن مسبقًا في Wiz Threat Intel Center للعثور على المثيلات الضعيفة لمجموعة أدوات NVIDIA Container Toolkit في بيئتهم.
الأولوية والسياق
يوصى بشدة بالتصحيح لجميع مضيفي الحاويات الذين يقومون بتشغيل إصدارات ضعيفة من مجموعة الأدوات. نظرًا لأن الاستغلال يتم تسليمه داخل صورة الحاوية نفسها، فإننا ننصح بإعطاء الأولوية للمضيفين الذين من المحتمل أن يقوموا بتشغيل حاويات مبنية من صور عامة أو غير موثوق بها. يمكن تحقيق المزيد من تحديد الأولويات من خلال التحقق من صحة وقت التشغيل لتركيز جهود التصحيح على الحالات التي تكون فيها مجموعة الأدوات الضعيفة قيد الاستخدام بشكل نشط.
من المهم ملاحظة أن التعرض للإنترنت ليس عاملاً ذا صلة بفرز هذه الثغرة الأمنية. لا يحتاج المضيف المتأثر إلى الكشف عنه علنًا. وبدلاً من ذلك، قد تتضمن متجهات الوصول الأولي محاولات الهندسة الاجتماعية ضد المطورين، أو سيناريوهات سلسلة التوريد حيث يكون لدى المهاجم وصول مسبق إلى مستودع صور الحاوية، أو أي بيئة تسمح للمستخدمين بتحميل صور عشوائية.
بالنسبة للأنظمة التي لا يمكن ترقيتها على الفور، قدمت NVIDIA العديد من خيارات التخفيف. الطريقة الأساسية هي إلغاء الاشتراك في استخدام enable-cuda-compat هوك، وهو مصدر التعرض.
لوقت تشغيل حاوية NVIDIA
عند استخدام NVIDIA Container Runtime في الوضع القديم، يمكنك تعطيل الارتباط عن طريق تحرير ملف /etc/nvidia-container-toolkit/config.toml الملف وإعداد features.disable-cuda-compat-lib-hook العلم ل true:
[features]
disable-cuda-compat-lib-hook = trueلمشغل GPU NVIDIA
عند استخدام NVIDIA GPU Operator، يمكنك تعطيل الربط عن طريق إضافة disable-cuda-compat-lib-hook إلى NVIDIA_CONTAINER_TOOLKIT_OPT_IN_FEATURES متغير البيئة. يمكن القيام بذلك عن طريق تضمين الوسائط التالية عند تثبيت مشغل GPU أو ترقيته باستخدام Helm:
--set
"toolkit.env[0].name=NVIDIA_CONTAINER_TOOLKIT_OPT_IN_FEATURES" \
--set
"toolkit.env[0].value=disable-cuda-compat-lib-hook"ملاحظة: يجب إضافة أي علامات ميزات أخرى كقائمة مفصولة بفواصل إلى ملف value مجال.
للمستخدمين مع إصدار مشغل GPU قبل 25.3.1، يمكنك نشر إصدار NVIDIA Container Toolkit المصحح 1.17.8 من خلال تضمين الوسائط التالية في أمر Helm الخاص بك:
--set "toolkit.version=v1.17.8-ubuntu20.04"ملاحظة: بالنسبة إلى Red Hat Enterprise Linux أو Red Hat OpenShift، يجب عليك تحديد v1.17.8-ubi8 علامة.
لماذا تبحث عن مجموعة أدوات حاوية NVIDIA؟
ثورة الذكاء الاصطناعي بأكملها مبنية على قوة وحدات معالجة الرسوميات NVIDIA. في السحابة، المكون الحاسم الذي يربط بشكل آمن التطبيقات المعبأة في حاويات بوحدات معالجة الرسومات هذه هو مجموعة أدوات حاوية NVIDIA.
ليست هذه هي المرة الأولى التي نكتشف فيها نقاط ضعف خطيرة في هذا المكون الأساسي. في العام الماضي، كشفت Wiz Research عن CVE-2024-0132، وهو عيب مماثل في الهروب من الحاويات سمح بالاستيلاء على المضيف بالكامل. تعد هذه النتائج جزءًا من بحثنا المستمر حول أمن سلسلة التوريد الخاصة بالذكاء الاصطناعي. نحن ندرس كل طبقة من طبقات الذكاء الاصطناعي، بدءًا من البنية التحتية (Hugging Face، وReplicate، وSAP AI Core) وحتى النماذج نفسها والبرمجيات المستخدمة لتشغيلها (Ollama)، لفهم المخاطر الواقعية في ظل تسابق العالم لتبني هذه التكنولوجيا الجديدة.
التحليل الفني
لا يكمن المسار إلى الهروب من هذه الحاوية في خطأ معقد في تلف الذاكرة، ولكن في التفاعل الدقيق بين مواصفات الحاوية ومكون مضيف موثوق به وخدعة Linux الكلاسيكية. يتطلب فهم الاستغلال النظر إلى ثلاثة أجزاء رئيسية: آلية ربط OCI، والخلل المحدد في تنفيذ NVIDIA، واستغلال هذا الخلل كسلاح.
تحدد مواصفات مبادرة الحاوية المفتوحة (OCI) معيارًا لأوقات تشغيل الحاوية. جزء من هذا المعيار هو نظام “الربط”، الذي يسمح للأدوات بتشغيل البرامج النصية في نقاط محددة في دورة حياة الحاوية. ال مجموعة أدوات حاوية NVIDIA (NCT) يستخدم هذه الخطافات لأداء وظيفته الأساسية: تكوين حاوية لتتمكن من التواصل مع برامج تشغيل NVIDIA ووحدات معالجة الرسومات الخاصة بالمضيف.
عند بدء تشغيل حاوية باستخدام وقت تشغيل NVIDIA، يقوم NCT بتسجيل العديد من الخطافات، بما في ذلك ما يلي createContainer خطاف:
"createContainer": [
{
"path": "/usr/bin/nvidia-ctk",
"args": ["nvidia-ctk", "hook", "enable-cuda-compat", "..."]
},
...
]
يعمل هذا الخطاف كعملية مميزة على المضيف لإعداد البيئة اللازمة للحاوية.
تحدد مواصفات OCI أنواعًا مختلفة من الخطافات. بينما prestart تعمل الخطافات في سياق نظيف ومعزول، createContainer الخطافات لها خاصية حاسمة: إنهم يرثون متغيرات البيئة من صورة الحاوية ما لم يتم تكوينها بشكل صريح على عدم القيام بذلك
وفقًا لمواصفات OCI على Github:
“… في نظام التشغيل Linux، قد يحدث هذا قبل pivot_root يتم تنفيذ العملية ولكن بعد إنشاء مساحة الاسم والإعداد.
مع القدرة على التحكم في بيئة الخطاف المميز، يكون لدى المهاجم العديد من الخيارات. واحدة من أكثر مباشرة هو سوء المعاملة LD_PRELOAD، وهو متغير بيئة Linux معروف وقوي. LD_PRELOAD يفرض عملية لتحميل مكتبة مشتركة محددة من قبل المستخدم (.so ملف).
عن طريق الإعداد LD_PRELOAD في ملف Dockerfile الخاص بهم، يمكن للمهاجم توجيه تعليمات إلى ملف nvidia-ctk ربط لتحميل مكتبة ضارة. ومما يزيد الطين بلة، أن createContainer يتم تنفيذ الخطاف مع تعيين دليل العمل الخاص به على نظام الملفات الجذر للحاوية. وهذا يعني أنه يمكن تحميل المكتبة الضارة مباشرة من صورة الحاوية بمسار بسيط، مما يكمل سلسلة الاستغلال.
الاستغلال: ملف عامل إرساء ثلاثي الأسطر
أحد الجوانب الأكثر إثارة للقلق في هذه الثغرة الأمنية هو بساطته. يحتاج المهاجم فقط إلى إنشاء صورة حاوية تحتوي على حمولة ضارة وملف Dockerfile التالي المكون من ثلاثة أسطر.
ملف Dockerfile الضار:
FROM busybox
ENV LD_PRELOAD=/proc/self/cwd/poc.so
ADD poc.so /عندما يتم تشغيل هذه الحاوية على نظام ضعيف، فإن nvidia-ctk createContainer الخطاف يرث LD_PRELOAD عامل. نظرًا لأن دليل عمل الخطاف هو نظام ملفات الحاوية، فإنه يقوم بتحميل ملف المهاجم poc.so file في عملية مميزة خاصة به، مما يؤدي على الفور إلى تحقيق الهروب من الحاوية.
لإثبات ذلك، لدينا poc.so يقوم الحمولة ببساطة بتشغيل أمر المعرف ويكتب الإخراج إليه /owned على المضيف.
تشغيل الثغرة:
# Build the malicious container
$ docker build . -t nct-exploit
# Run it on a host with the vulnerable NVIDIA Container Toolkit
$ docker run --rm --runtime=nvidia --gpus=all nct-exploitالنتيجة: الجذر على المضيف
الجدول الزمني للإفصاح المسؤول
-
17 مايو 2025: تم إرسال تقرير الضعف الأولي إلى NVIDIA في Pwn2Own Berlin.
-
15 يوليو 2025: نشرت NVIDIA نشرة الأمان وخصصت CVE-2025-23266.
-
17 يوليو 2025: تنشر Wiz Research منشور المدونة هذا.
عند مناقشة أمن الذكاء الاصطناعي، فإن هذه الثغرة الأمنية تسلط الضوء مرة أخرى على أن الخطر الحقيقي والمباشر لتطبيقات الذكاء الاصطناعي اليوم يأتي من بنيتها التحتية وأدواتها الأساسية. في حين أن الضجيج حول المخاطر الأمنية للذكاء الاصطناعي يميل إلى التركيز على الهجمات المستقبلية القائمة على الذكاء الاصطناعي، فإن نقاط ضعف البنية التحتية “التقليدية” في مجموعة تقنيات الذكاء الاصطناعي المتزايدة باستمرار تظل تشكل التهديد المباشر الذي يجب على فرق الأمن إعطاء الأولوية له.
إن سطح الهجوم العملي هذا هو نتيجة التقديم السريع لأدوات وخدمات الذكاء الاصطناعي الجديدة. لذلك، من الضروري أن تعمل فرق الأمان بشكل وثيق مع مهندسي الذكاء الاصطناعي لديهم للحصول على رؤية واضحة للبنية والأدوات ونماذج الذكاء الاصطناعي المستخدمة. على وجه التحديد، كما توضح هذه الثغرة الأمنية، من المهم بناء مسار ناضج لتشغيل نماذج الذكاء الاصطناعي مع التحكم الكامل في مصدرها وسلامتها.
بالإضافة إلى ذلك، يسلط هذا البحث الضوء، وليس للمرة الأولى، على ذلك لا تشكل الحاويات حاجزًا أمنيًا قويًا ولا ينبغي الاعتماد عليها كوسيلة وحيدة للعزل. عند تصميم التطبيقات، خاصة للبيئات متعددة المستأجرين، يجب على المرء دائمًا “افتراض وجود ثغرة أمنية” وتنفيذ حاجز عزل قوي واحد على الأقل، مثل المحاكاة الافتراضية (كما هو موضح في إطار عمل PEACH). لقد كتب Wiz Research حول هذه المشكلة على نطاق واسع، ويمكنك قراءة المزيد عنها في بحثنا السابق حول Alibaba Cloud وIBM وAzure وHugging Face وReplicate وSAP.
ابق على اتصال!
أهلاً! نحن نير أوهفيلد (@nirohfeld)، وساغي تساديك (@sagitz_)، ورونين شوستين (@ronenshh)، وهيلاي بن ساسون (@hillai)، وأندريس ريانشو (@andresriancho)، ويوفال أفراهامي (@yuvalavra) من فريق أبحاث Wiz (@wiz_io). نحن مجموعة من المتسللين ذوي القبعة البيضاء المخضرمين بهدف واحد: جعل السحابة مكانًا أكثر أمانًا للجميع. نحن نركز بشكل أساسي على العثور على نواقل هجوم جديدة في السحابة والكشف عن مشكلات العزل لدى بائعي السحابة ومقدمي الخدمات. نحن نحب أن نسمع منك! لا تتردد في الاتصال بنا على X (Twitter) أو عبر البريد الإلكتروني: Research@wiz.io.
