أولاما يعد واحدًا من أكثر المشاريع مفتوحة المصدر شيوعًا لتشغيل نماذج الذكاء الاصطناعي، مع أكثر من 70 ألف نجم جيثب ومئات الآلاف من عمليات السحب الشهرية مركز عامل الميناء. مستوحاة من Docker، تهدف Ollama إلى تبسيط عملية التعبئة ونشر نماذج الذكاء الاصطناعي.
اكتشفت Wiz Research ثغرة أمنية سهلة الاستغلال في تنفيذ التعليمات البرمجية عن بعد في Ollama: CVE-2024-37032، يطلق عليها اسم “Probllama”. تم الكشف عن هذه المشكلة الأمنية بشكل مسؤول لمشرفي Ollama وتم تخفيفها منذ ذلك الحين. يتم تشجيع مستخدمي Ollama على ترقية تثبيت Ollama إلى الإصدار 0.1.34 أو الأحدث.
يشير بحثنا إلى أنه اعتبارًا من 10 يونيو، هناك عدد كبير من مثيلات Ollama التي تقوم بتشغيل إصدار ضعيف ومكشوف على الإنترنت. في منشور المدونة هذا، سنشرح بالتفصيل ما وجدناه وكيف وجدناه، بالإضافة إلى تقنيات التخفيف والتدابير الوقائية التي يمكن للمؤسسات اتخاذها للمضي قدمًا.
بشكل عام – وفي ضوء التركيز المستمر لفريق Wiz Research على المخاطر الكامنة في أنظمة الذكاء الاصطناعي – تؤكد النتائج التي توصلنا إليها حقيقة أن تدابير أمان الذكاء الاصطناعي قد تم تهميشها إلى حد كبير لصالح التركيز على القوة التحويلية لهذه التكنولوجيا، وقدرتها على إحداث ثورة في الطريقة التي تتم بها الأعمال.
تتبنى المؤسسات بسرعة مجموعة متنوعة من أدوات الذكاء الاصطناعي والبنية التحتية الجديدة في محاولة لتعزيز قدرتها التنافسية. غالبًا ما تكون هذه الأدوات في مرحلة مبكرة من التطوير وتفتقر إلى ميزات الأمان القياسية، مثل المصادقة. بالإضافة إلى ذلك، نظرًا لقاعدة الأكواد البرمجية الحديثة الخاصة بها، فمن الأسهل نسبيًا العثور على نقاط الضعف المهمة في البرامج، مما يجعلها أهدافًا مثالية لممثلي التهديد المحتملين. هذا موضوع متكرر في اكتشافاتنا – راجع أعمال Wiz Research السابقة حول مقدمي خدمات الذكاء الاصطناعي تعانق الوجه و تكرار، وكذلك لدينا حالة الذكاء الاصطناعي في السحابة تقرير و اكتشاف 38 تيرابايت من البيانات العام الماضي والتي تم تسريبها عن طريق الخطأ من قبل باحثي الذكاء الاصطناعي.
خلال العام الماضي، تم تحديد العديد من نقاط الضعف في تنفيذ التعليمات البرمجية عن بعد (RCE) في خوادم الاستدلال، بما في ذلك TorchServe وRay Anyscale وOllama. يمكن أن تسمح نقاط الضعف هذه للمهاجمين بالاستيلاء على خوادم استدلال الذكاء الاصطناعي المستضافة ذاتيًا، وسرقة نماذج الذكاء الاصطناعي أو تعديلها، واختراق تطبيقات الذكاء الاصطناعي.
لا تكمن المشكلة الحاسمة في نقاط الضعف نفسها فحسب، بل في النقص المتأصل في دعم المصادقة في هذه الأدوات الجديدة. في حالة تعرضه للإنترنت، يمكن لأي مهاجم الاتصال بها، أو سرقة نماذج الذكاء الاصطناعي أو تعديلها، أو حتى تنفيذ تعليمات برمجية عن بعد كميزة مدمجة (كما هو موضح في TorchServe وTorchServe). راي أنيسكيل). ويعني نقص دعم المصادقة أن هذه الأدوات لا ينبغي أبدًا أن يتم كشفها خارجيًا بدون برامج وسيطة وقائية، مثل الوكيل العكسي مع المصادقة. على الرغم من ذلك، عند فحص الإنترنت بحثًا عن خوادم Ollama المكشوفة، كشف فحصنا عن أكثر من 1000 مثيل مكشوف يستضيف العديد من نماذج الذكاء الاصطناعي، بما في ذلك النماذج الخاصة غير المدرجة في مستودع Ollama العام، مما يسلط الضوء على فجوة أمنية كبيرة.
لاستغلال هذه الثغرة الأمنية، يجب على المهاجم إرسال طلبات HTTP مصممة خصيصًا إلى خادم Olmaa API. في تثبيت Linux الافتراضي، يرتبط خادم API بالمضيف المحلي، مما يقلل من مخاطر الاستغلال عن بعد بشكل كبير. ومع ذلك، في عمليات نشر عامل الإرساء (أولاما / أولاما)، خادم API مكشوف للعامةوبالتالي يمكن استغلالها عن بعد.
يمكن لعملاء Wiz استخدام الاستعلام والاستشارات المعدة مسبقًا في Wiz Threat Center للبحث عن المثيلات الضعيفة في بيئتهم.
لماذا البحث في أولاما؟
يبذل فريق البحث لدينا جهدًا نشطًا للمساهمة في أمان خدمات الذكاء الاصطناعي وأدواته وبنيته التحتية، كما نستخدم الذكاء الاصطناعي في عملنا البحثي.
بالنسبة لمشروع مختلف، كنا نتطلع إلى الاستفادة من نموذج الذكاء الاصطناعي واسع السياق. ولحسن الحظ، في ذلك الوقت تقريبًا، أصدرت Gradient إصدار Llama3 الخاص بها والذي يحتوي على سياق مليون رمز مميز.
كونه واحدًا من أكثر المشاريع مفتوحة المصدر شيوعًا لتشغيل نماذج الذكاء الاصطناعي مع أكثر من 70 ألف نجم جيثب ومئات الآلاف من عمليات السحب الشهرية مركز عامل الميناء، يبدو أن أولاما هي أبسط طريقة للاستضافة الذاتية هذا النموذج 😊.
العمارة أولاما
يتكون Ollama من مكونين رئيسيين: العميل والخادم. يكشف الخادم واجهات برمجة التطبيقات المتعددة لأداء الوظائف الأساسية، مثل سحب نموذج من السجل، وإنشاء تنبؤ لموجه معين، وما إلى ذلك. العميل هو ما يتفاعل معه المستخدم (أي الواجهة الأمامية)، والذي يمكن أن يكون، على سبيل المثال، واجهة سطر الأوامر (CLI).
أثناء تجربة Ollama، اكتشف فريقنا ثغرة أمنية خطيرة في خادم Ollama. نظرًا لعدم كفاية التحقق من صحة الإدخال، فمن الممكن استغلال ملف اجتياز المسار ثغرة أمنية في الكتابة فوق الملفات الموجودة على الخادم بشكل تعسفي. ويمكن استغلال ذلك بشكل أكبر في التنفيذ الكامل للتعليمات البرمجية عن بُعد كما هو موضح أدناه.
هذه المشكلة خطيرة للغاية في عمليات تثبيت Docker، حيث يعمل الخادم معها root الامتيازات ويستمع على 0.0.0.0 بشكل افتراضي – والذي يتيح استغلال هذه الثغرة الأمنية عن بعد.
من المهم الإشارة إلى أن Ollama لا يدعم المصادقة الجاهزة. يوصى به بشكل عام نشر Ollama خلف وكيل عكسي لفرض المصادقة، إذا قرر المستخدم الكشف عن تثبيته. ومن الناحية العملية، تشير أبحاثنا إلى أن هناك عددًا كبيرًا من عمليات التثبيت المكشوفة على الإنترنت دون أي نوع من المصادقة.
الثغرة الأمنية: كتابة ملف عشوائي عبر اجتياز المسار
يكشف خادم HTTP الخاص بـ Ollama نقاط نهاية API متعددة التي تؤدي إجراءات مختلفة.
إحدى نقاط النهاية،/api/pull، يمكن استخدامه لتنزيل نموذج من سجل Ollama.
افتراضيًا، يتم تنزيل النماذج من سجل Olma الرسمي (registry.ollama.com)، ومع ذلك، من الممكن أيضًا جلب النماذج من السجلات الخاصة.
في حين يمكن اعتبار السجل الرسمي لـ Ollama “موثوقًا”، يمكن لأي شخص إعداد السجل الخاص به واستضافة النماذج عليه. كباحثين، كنا مهتمين بسطح الهجوم هذا – هل يتم الوثوق بالسجلات الخاصة بشكل أعمى؟ ما الضرر الذي يمكن أن يسببه التسجيل الخاص الضار؟
ما وجدناه هو أنه عند سحب نموذج من سجل خاص (من خلال الاستعلام عن ملف http://[victim]:11434/api/pull نقطة نهاية واجهة برمجة التطبيقات)، فمن الممكن توفير ملف بيان ضار يحتوي على حمولة اجتياز المسار في الملف digest مجال.
مثال:
{
"schemaVersion": 2,
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"config": {
"mediaType": "application/vnd.docker.container.image.v1+json",
"digest": "../../../../../../../../../../../../../../../../../../../traversal",
"size": 5
},
"layers": [
{
"mediaType": "application/vnd.ollama.image.license",
"digest": "../../../../../../../../../../../../../../../../../../../../../traversal",
"size": 7020
}
]
}
ال digest يجب أن يكون حقل طبقة معينة مساوياً لتجزئة الطبقة. من بين أمور أخرى، digest تُستخدم الطبقة أيضًا لتخزين ملف النموذج على القرص:
/root/.ollama/models/blobs/sha256-04778965089b91318ad61d0995b7e44fad4b9a9f4e049d7be90932bf8812e828
ومع ذلك، وجدنا أن digest مجال كان يُستخدم دون التحقق المناسب من الصحة، مما يؤدي إلى اجتياز المسار عند محاولة تخزينه على نظام الملفات. يمكن استغلال هذه المشكلة لإفساد الملفات التعسفية الموجودة على النظام.
تحقيق قراءة الملف التعسفي
من خلال استغلال المشكلة السابقة، يمكننا زرع ملف بيان ضار إضافي على الخادم (على سبيل المثال/root/.ollama/models/manifests/%ATTACKER_IP%/library/manifest/latest)، والذي يقوم بتسجيل نموذج جديد على الخادم بشكل فعال. لقد اكتشفنا أنه إذا كان بيان نموذجنا يحتوي على حمولة اجتياز لـ digest إحدى طبقاته، عند محاولة دفع هذا النموذج إلى سجل بعيد عبر ملف http://[victim]:11434/api/push نقطة النهاية، سيقوم الخادم بتسريب محتوى الملف المحدد في ملف digest مجال.
وأخيرا، تنفيذ التعليمات البرمجية عن بعد
كما ذكرنا سابقًا، من الممكن استغلال ثغرة Arbitrary File Write لإتلاف ملفات معينة في النظام. في عمليات تثبيت Docker، من السهل جدًا استغلالها وتحقيق تنفيذ التعليمات البرمجية عن بُعد، أثناء تشغيل الخادمroot الامتيازات.
إن أبسط طريقة فكرنا بها لتحقيق تنفيذ التعليمات البرمجية عن بعد هي إفسادها ld.so ملفات التكوين، على وجه التحديد /etc/ld.so.preload. يحتوي هذا الملف على مسافة بيضاء –قائمة منفصلة بالمكتبات المشتركة التي يجب تحميلها عند بدء عملية جديدة. باستخدام برنامج استغلال الكتابة التعسفية للملفات البدائي، نقوم بزرع حمولتنا كمكتبة مشتركة على نظام الملفات (/root/bad.so) ثم نفسد etc/ld.so.preload لإدراجه. وأخيراً نقوم بالاستعلام عن /api/chat نقطة النهاية على خادم Ollama API، والتي تقوم لاحقًا بإنشاء عملية جديدة وبالتالي تحميل حمولتنا!
فيما يتعلق باستغلال الحالات التي لا تعمل معها root الامتيازات – لدينا استراتيجية للاستغلال تعمل على الاستفادة من قراءة الملفات التعسفية / البدائية. ومع ذلك، سيتم تركها كتمرين للقارئ 😊
CVE-2024-37032 هو تنفيذ تعليمات برمجية عن بعد سهل الاستغلال ويؤثر على البنية التحتية الحديثة للذكاء الاصطناعي. على الرغم من كون قاعدة التعليمات البرمجية جديدة نسبيًا ومكتوبة بلغات البرمجة الحديثة، إلا أن نقاط الضعف الكلاسيكية مثل اجتياز المسار تظل مشكلة.
يجب على فرق الأمان تحديث مثيلات Ollama الخاصة بهم إلى الإصدار الأحدث للتخفيف من هذه الثغرة الأمنية. علاوة على ذلك، يوصى بعدم كشف Ollama على الإنترنت ما لم يكن محميًا بنوع ما من آليات المصادقة، مثل الوكيل العكسي.
لقد كشفنا بشكل مسؤول عن هذه الثغرة الأمنية لفريق تطوير Ollama في مايو 2024. وقام Ollama على الفور بالتحقيق في المشكلة ومعالجتها مع إبقائنا على اطلاع دائم.
-
5 مايو 2024 – أبلغت شركة Wiz Research بالمشكلة إلى Olma.
-
5 مايو 2024 – أقر علماء باستلام التقرير.
-
5 مايو 2024 – أبلغ Ollama شركة Wiz Research بأنهم قاموا بإصلاح GitHub.
-
8 مايو 2024 – أصدرت شركة Ollama نسخة مصححة.
-
24 يونيو 2024 – نشرت Wiz Research مدونة حول هذه القضية.
التزمت شركة Ollama بالإصلاح في غضون 4 ساعات تقريبًا بعد تلقي تقريرنا الأولي، مما يدل على وقت استجابة مثير للإعجاب والتزام بأمن منتجاتها.
