كشفت Wiz Research عن ثغرة أمنية خطيرة، CVE-2024-0132، في مجموعة أدوات حاوية NVIDIA المستخدمة على نطاق واسع، والتي توفر لتطبيقات الذكاء الاصطناعي المعبأة في حاويات إمكانية الوصول إلى موارد وحدة معالجة الرسومات. يؤثر هذا على أي تطبيق ذكاء اصطناعي – في السحابة أو محليًا – يقوم بتشغيل مجموعة أدوات الحاوية الضعيفة لتمكين دعم وحدة معالجة الرسومات.
تتيح الثغرة الأمنية للمهاجمين الذين يتحكمون في صورة الحاوية التي يتم تنفيذها بواسطة مجموعة الأدوات الضعيفة الهروب من تلك الحاوية والحصول على حق الوصول الكامل إلى النظام المضيف الأساسي، مما يشكل خطرًا كبيرًا على البيانات الحساسة والبنية التحتية.
في 26 سبتمبر، نفيديا اصدرت نشرة أمنية بالإضافة إلى نسخة مصححة من المنتج المتأثر. شكرًا لفريق NVIDIA بأكمله الذي عمل معنا طوال عملية الكشف. نحن نقدر بشدة شفافيتهم واستجابتهم وتعاونهم خلال هذه المشاركة.
في هذا المنشور، سنقدم نظرة عامة رفيعة المستوى حول هذا الاكتشاف وآثاره. نظرًا لانتشار هذا الخطأ وحساسيته، سنحفظ بعض التفاصيل الفنية للإصدار المستقبلي، مع حذف معلومات الاستغلال في الوقت الحالي حتى يتوفر لدى المؤسسات المتأثرة الوقت لمعالجة الثغرة الأمنية.
يتم تشجيع المؤسسات التي تستخدم مجموعة أدوات حاوية NVIDIA بشدة على تحديث الحزمة المتأثرة إلى الإصدار الأحدث 1.16.2، مع التركيز على مضيفي الحاويات الذين قد يقومون بتشغيل صور حاوية غير موثوقة.
اكتشف Wiz Research ثغرة أمنية في الهروب من الحاوية (CVE-2024-0132) تؤثر على مكتبة NVIDIA Container Toolkit المستخدمة على نطاق واسع، من شأنه أن يسمح مهاجم يتحكم في صور الحاوية التي تديرها مجموعة الأدوات لتنفيذ عملية الهروب من الحاوية والحصول على حق الوصول الكامل إلى المضيف الأساسي.
تعتمد درجة السرعة التي يجب بها إصلاح الثغرة الأمنية على بنية بيئتك ومستوى الثقة التي تضعها في تشغيل الصور. أي بيئة تسمح باستخدام صور حاوية تابعة لجهات خارجية أو نماذج الذكاء الاصطناعي – سواء داخليًا أو كخدمة – تكون أكثر عرضة للخطر نظرًا لإمكانية استغلال هذه الثغرة الأمنية عبر صورة ضارة.
بعض الأمثلة التوضيحية:
-
بيئات الحوسبة ذات المستأجر الواحد: إذا قام أحد المستخدمين بتنزيل صورة حاوية ضارة من مصدر غير موثوق به (نتيجة لهجوم هندسة اجتماعية، على سبيل المثال)، فيمكن للمهاجم بعد ذلك الاستيلاء على محطة عمل المستخدم.
-
البيئات المنظمة: في البيئات المشتركة مثل Kubernetes (K8s)، يمكن للمهاجم الذي لديه إذن بنشر حاوية الهروب من تلك الحاوية والوصول إلى البيانات وأسرار التطبيقات الأخرى التي تعمل على نفس العقدة – أو حتى على نفس المجموعة – وبالتالي التأثير على البيئة بأكملها.
في حين أن السيناريو الثاني ينطبق على أي مؤسسة تقوم بتشغيل نموذج حوسبة مشترك، إلا أنه ذو صلة بشكل خاص بـ مزودو خدمات الذكاء الاصطناعي الذين يسمحون للعملاء بتشغيل صور الحاويات الخاصة بهم التي تدعم وحدة معالجة الرسومات. وفي هذه الحالة، تصبح الثغرة الأمنية أكثر خطورة. يمكن للمهاجم نشر حاوية ضارة والخروج منها واستخدام أسرار الجهاز المضيف لاستهداف أنظمة التحكم في الخدمة السحابية. وقد يمنح ذلك المهاجم إمكانية الوصول إلى معلومات حساسة، مثل الكود المصدري والبيانات وأسرار العملاء الآخرين الذين يستخدمون نفس الخدمة.
الخلفية: ما هي مجموعة أدوات حاوية NVIDIA؟
يتيح تشغيل وحدات معالجة الرسومات في بيئة حسابية مشتركة مشاركة وحدة معالجة رسومات واحدة عبر أعباء عمل مختلفة وربما مستخدمين مختلفين. لتمكين الوصول إلى وحدة معالجة الرسومات الأصلية من داخل بيئة الحاوية، قامت NVIDIA ببناء مجموعة من برامج التشغيل والأدوات التي يتم نشرها على مضيف الحاوية وتتكامل مع وقت تشغيل الحاوية.
تعد مجموعة أدوات NVIDIA Container Toolkit هي المعيار الصناعي لهذا التكامل، مما يسهل الاستخدام السلس لوحدة معالجة الرسومات داخل البيئات المعبأة في حاويات. وفي السنوات الأخيرة، أصبحت مجموعة الأدوات ذات شعبية متزايدة، بالتوازي مع النمو الهائل في الذكاء الاصطناعي وتقنيات الحاويات.
تم اعتماد هذه المكتبة على نطاق واسع باعتبارها الحل المدعوم من NVIDIA للوصول إلى وحدة معالجة الرسومات داخل الحاويات. علاوة على ذلك، يتم تثبيته مسبقًا في العديد من منصات الذكاء الاصطناعي وصور الآلة الافتراضية (AMIs)، حيث إنه أحد متطلبات البنية التحتية الشائعة لتطبيقات الذكاء الاصطناعي.
مشغل NVIDIA GPU هو مشغل Kubernetes الذي يقوم تلقائيًا بنشر وإدارة مجموعة أدوات حاوية NVIDIA في مجموعات Kubernetes. يؤدي اعتمادها على نطاق واسع في بيئات Kubernetes التي تدعم وحدة معالجة الرسومات إلى توسيع نطاق مجموعة أدوات حاوية NVIDIA بشكل كبير، مما يجعلها موجودة في أعباء عمل وحدة معالجة الرسومات الأكثر احتواءًا عبر المؤسسات المختلفة.
المكونات المتضررة:
ملحوظة: لا تؤثر الثغرة الأمنية على حالات الاستخدام التي يتم فيها استخدام واجهة جهاز الحاوية (CDI).
يجب على المؤسسات المتأثرة الترقية إلى أحدث إصدار من Container Toolkit (v1.16.2) وNVIDIA GPU Operator (v24.6.2).
يوصى بشدة بالتصحيح لمضيفي الحاويات الذين يقومون بتشغيل Container Toolkit في الإصدارات الضعيفة، مع إعطاء الأولوية للمضيفين الذين من المحتمل أن يقوموا بتشغيل الحاويات، خاصة تلك المبنية من صور منشؤها مصادر غير موثوقة. يمكن تحقيق المزيد من تحديد الأولويات من خلال التحقق من صحة وقت التشغيل، وذلك لتركيز جهود التصحيح على الحالات التي تكون فيها مجموعة الأدوات قيد الاستخدام بالتأكيد.
لاحظ أن التعرض للإنترنت ليس عاملاً ذا صلة بفرز هذه الثغرة الأمنية، حيث لا يحتاج مضيف الحاوية المتأثر إلى الكشف عنه علنًا من أجل تحميل صورة حاوية ضارة. وبدلاً من ذلك، قد تتضمن متجهات الوصول الأولية محاولات الهندسة الاجتماعية ضد المطورين؛ سيناريوهات سلسلة التوريد مثل وجود مهاجم لديه حق الوصول المسبق إلى مستودع صور الحاوية؛ والبيئات الحاوية التي تسمح للمستخدمين الخارجيين بتحميل صور عشوائية (سواء عن طريق التصميم أو بسبب التكوين الخاطئ).
في سياق عملنا في التحقيق مع مقدمي خدمات الذكاء الاصطناعي (تعانق الوجه, تكرار, ساب منظمة العفو الدولية الأساسية، وآخرون)، حدد باحثو Wiz أن هؤلاء المزودين يميلون إلى تشغيل نماذج الذكاء الاصطناعي وإجراءات التدريب كحاويات في بيئات الحوسبة المشتركة، حيث تشترك تطبيقات متعددة من عملاء مختلفين في نفس جهاز GPU. أثارت هذه الرؤية سؤالًا بحثيًا مثيرًا للاهتمام: هل يمكن لجهاز GPU المشترك أن يسمح بالوصول إلى نماذج الذكاء الاصطناعي أو المطالبات أو مجموعات البيانات الخاصة بالعملاء الآخرين؟ قادنا هذا إلى التحقق من وحدات Kernel وSDK وأدوات وقت التشغيل الخاصة بـ NVIDIA.
عندما واجهنا مجموعة أدوات NVIDIA Container Toolkit، اكتشفنا سطح هجوم واسعًا لثغرات اختراق الحاوية، مما قد يسمح لنا بالهروب من الحاوية الخاصة بنا في الخدمة والوصول إلى بيانات العملاء الآخرين الذين يشاركون نفس موارد GPU. قادنا هذا الاكتشاف إلى تنحية أبحاثنا التي تركز على وحدة معالجة الرسومات جانبًا والتعمق أكثر في الأدوات المساعدة التي توفرها NVIDIA لعملائها.
يتكون الهجوم من ثلاث مراحل رئيسية:
-
إنشاء صورة ضارة: يقوم المهاجم بإنشاء صورة مصممة خصيصًا لاستغلال CVE-2024-0132. (ملاحظة: لا يتم توفير تفاصيل فنية محددة حول استغلال هذه الثغرة الأمنية في هذه المرحلة للأسباب التي ذكرناها سابقًا.)
-
الوصول الكامل إلى نظام الملفات: يقوم المهاجم بتشغيل الصورة الضارة على النظام الأساسي المستهدف. يمكن تنفيذ ذلك إما بشكل مباشر (على سبيل المثال في الخدمات التي تسمح بموارد GPU المشتركة) أو بشكل غير مباشر من خلال سلسلة التوريد أو هجوم الهندسة الاجتماعية (على سبيل المثال، قيام مستخدم بتشغيل صورة AI من مصدر غير موثوق به). من خلال استغلال الثغرة الأمنية، يكتسب المهاجم القدرة على تحميل نظام الملفات المضيف بأكمله، والحصول على حق الوصول الكامل للقراءة إلى المضيف الأساسي. وهذا يمنح المهاجم رؤية كاملة للبنية التحتية الأساسية، ومن المحتمل أن يسمح بالوصول إلى البيانات السرية للعملاء الآخرين.
-
الاستيلاء الكامل على المضيف: من خلال هذا الوصول، يمكن للمهاجم الآن الوصول إلى مآخذ توصيل Container Runtime Unix (
docker.sock/containerd.sock). يمكن استخدام هذه المقابس لتنفيذ أوامر عشوائية على النظام المضيف بامتيازات الجذر، والتحكم بشكل فعال في الجهاز (هذا مسار هجوم معروف للأنظمة المعبأة في حاويات، راجع هنا). لاحظ أن بينما تمنح الثغرة الأمنية في البداية حق الوصول للقراءة فقط إلى نظام الملفات، يمكن للمهاجم استغلال فارق بسيط في سلوك مأخذ توصيل Unix. في Linux، تظل المقابس قابلة للكتابة حتى عند تثبيتها بأذونات القراءة فقط.
-
1 سبتمبر 2024 – تقوم Wiz Research بالإبلاغ عن الثغرة الأمنية إلى فريق الاستجابة للحوادث الأمنية لمنتج NVIDIA (PSIRT).
-
3 سبتمبر 2024 – تقر NVIDIA بالتقرير.
-
26 سبتمبر 2024 – تقوم NVIDIA بإصلاح الثغرة الأمنية المبلغ عنها وشحن نسخة مصححة.
عند مناقشة المخاطر الأمنية للذكاء الاصطناعي، فإن هذه الثغرة الأمنية تسلط الضوء مرة أخرى على أن المخاطر الأمنية الحقيقية والمباشرة لتطبيقات الذكاء الاصطناعي اليوم تأتي من البنية التحتية للذكاء الاصطناعي وأدواته.
في حين أن الضجيج المتعلق بالمخاطر الأمنية للذكاء الاصطناعي يميل إلى التركيز على الهجمات المستقبلية المستندة إلى الذكاء الاصطناعي، فإن نقاط ضعف البنية التحتية “التقليدية” في مجموعة تقنيات الذكاء الاصطناعي المتنامية باستمرار تظل الخطر المباشر الذي يجب على فرق الأمن إعطاء الأولوية والحماية منه.
إن سطح الهجوم العملي هذا هو نتيجة التقديم السريع لأدوات وخدمات الذكاء الاصطناعي الجديدة، وبالتالي من الضروري أن تعمل فرق الأمان بشكل وثيق مع مهندسي الذكاء الاصطناعي لديهم، والحصول على رؤية واضحة للبنية والأدوات ونماذج الذكاء الاصطناعي المستخدمة. على وجه التحديد، كما نرى في حالة هذه الثغرة الأمنية، من المهم بناء مسار ناضج لتشغيل نماذج الذكاء الاصطناعي مع التحكم الكامل في مصدر وسلامة النماذج نفسها.
بالإضافة إلى ذلك، يسلط هذا البحث الضوء، وليس للمرة الأولى، على أن الحاويات ليست حاجزًا أمنيًا قويًا ولا ينبغي الاعتماد عليها كوسيلة وحيدة للعزل. عندما نقوم بتصميم التطبيقات، وخاصة التطبيقات متعددة المستأجرين، يجب علينا دائمًا “افتراض وجود ثغرة أمنية” والتصميم بحيث يكون لدينا حاجز عزل قوي واحد على الأقل مثل المحاكاة الافتراضية (كما هو موضح في إطار الخوخ) . لقد كتب Wiz Research عن هذه القضية على نطاق واسع؛ يمكنك قراءة المزيد عنها في مدوناتنا البحثية السابقة على علي بابا كلاود, آي بي إم, أزور, تعانق الوجه, تكرار، و ساب.
لاحظ أن منشور المدونة هذا يحذف بعض التفاصيل الفنية. وسنقوم قريبًا بنشر “الجزء الثاني” الذي يشارك فيه المزيد من المعلومات التقنية المتعلقة بهذا الاكتشاف. نحن نؤجل الكشف عن هذه التفاصيل في الوقت الحالي من أجل منح المؤسسات الوقت لتقييم وتخفيف هذه الثغرة الأمنية في بيئاتها.
