Russellb

تفتقر معالجة التضمينات متعددة الوسائط إلى التحقق من صحة التنسور المتفرق. ونظرًا لأن PyTorch يعطل عمليات التحقق من ثبات التنسور المتفرق بشكل افتراضي، يمكن للمهاجم إرسال طلبات تضمين مصممة خصيصًا تحتوي على مؤشرات تنسور مشوهة، مثل القيم السالبة أو القيم خارج النطاق، عند تمكين ميزة `prompt-embeds`. وقد يؤدي ذلك إلى تعطل النظام، أو استنفاد الموارد مما يؤدي إلى رفض الخدمة، أو احتمال حدوث تلف في الذاكرة خارج النطاق أو كتابة البيانات في أماكن غير مخصصة لها.

vLLM هو آلية استدلال وخدمة للنماذج اللغوية الكبيرة (LLMs). آلية التحقق من صحة مفتاح واجهة برمجة التطبيقات (API) في الإصدارات الأقدم من 0.11.0rc2 معرضة لهجوم استغلال الوقت. تستغرق مقارنة السلاسل المستخدمة في عملية التحقق وقتًا أطول كلما زاد عدد الأحرف في مفتاح واجهة برمجة التطبيقات (API) المقدم التي تتطابق مع المفتاح المتوقع. من خلال تحليل الوقت المستغرق في محاولات التحقق المتعددة، يمكن للمهاجم تحديد الأحرف الصحيحة في تسلسل المفتاح، مما يؤدي إلى تجاوز عملية المصادقة. عملية التحقق من صحة مفتاح API معرضة للخطر.

تفشل الخلفية (backend) لـ vLLM المستخدمة مع نقطة نهاية واجهة برمجة التطبيقات (API) ”/v1/chat/completions“ في التحقق من صحة المدخلات غير المتوقعة أو غير الصحيحة في الحقول `pattern` و`type` عند استدعاء وظيفة الأدوات. لا يتم التحقق من صحة هذه المدخلات قبل تجميعها أو تحليلها، مما يتسبب في حدوث عطل خطير في وحدة الاستدلال (worker) عند تلقي طلب واحد فقط. وستظل وحدة الاستدلال غير متاحة حتى يتم إعادة تشغيلها. يُتوقع أن يكون الحقل `type` أحد الخيارات التالية: ”string“ أو ”number“ أو ”object“ أو ”boolean“ أو ’array‘ أو ”null“. سيؤدي توفير أي قيمة أخرى إلى حدوث عطل خطير في وحدة العمل. يخضع الحقل `pattern` لعملية العرض قبل أن يتم تمريره بشكل غير آمن إلى مُركِّب تعبيرات regex الأصلي دون التحقق من صحته أو إخراجه، مما يسمح للتعبيرات غير الصحيحة بالوصول إلى آلية regex C++ الأساسية، مما يؤدي إلى أخطاء فادحة.

توجد مشكلات متعددة تتعلق برفض الخدمة عبر التعبيرات النمطية (ReDoS)، حيث تتعرض عدة أنماط من التعبيرات النمطية لظاهرة «التراجع الكارثي» — وهي حالة تستغرق فيها التعبيرات النمطية المعقدة وقتًا أسيًّا لمعالجة مدخلات معينة. ويمكن أن يحدث ذلك عندما يقوم المهاجم بإرسال مدخلات مصممة خصيصًا ذات هياكل متداخلة أو متكررة، مما يؤدي إلى استهلاك شديد لموارد وحدة المعالجة المركزية (CPU) وتدهور الأداء. وتشمل المكونات المتأثرة نقطة نهاية الدردشة المتوافقة مع OpenAI، ومحلل أداة phi4mini، وملف `vllm/lora/utils.py`.

تؤثر هذه المشكلة على vLLM، وهو آلية استدلال وتقديم خدمات لنماذج اللغة الكبيرة (LLMs) عالية الإنتاجية وفعالة في استخدام الذاكرة. في حالة نشر vLLM على عدة عقد، يستخدم vLLM ZeroMQ لبعض أغراض الاتصال بين العقد، حيث يفتح مقبس XPUB ZeroMQ ويربطه بجميع الواجهات. وهذا يسمح لأي عميل لديه وصول إلى الشبكة بالاتصال بالمقبس، ما لم يتم حظر منفذه بواسطة جدار حماية، وتلقي معلومات داخلية عن حالة vLLM. وعلى الرغم من أن هذه البيانات ليست مفيدة للمهاجم، فإن الاتصال بالمقبس عدة مرات دون قراءة البيانات المنشورة قد يتسبب في حدوث رفض الخدمة، مما يؤدي إلى إبطاء أو احتمال تعطيل الناشر.

تنشأ المشكلة من آلية التخزين المؤقت للبادئة في vLLM، مما قد يعرض النظام لهجوم قناة جانبية عبر التوقيت. عند معالجة موجه جديد، إذا عثرت آلية PageAttention على جزء بادئة مطابق، يتم تسريع عملية التعبئة المسبقة، وهو ما ينعكس على «زمن الوصول إلى الرمز الأول» (TTFT). وتعد الاختلافات في التوقيت الناتجة عن الأجزاء المطابقة كبيرة بما يكفي ليتم تحديدها واستغلالها، مما قد يؤدي إلى تسرب المعلومات الخاصة. يمكن للمهاجم محاولة تخمين مدخلات الضحية عن طريق قياس TTFT استنادًا إلى تطابقات البادئة، مما يتيح له التحقق من صحة تخمينه.

اسم البرنامج المعرض للخطر والإصدارات المتأثرة: إصدارات XGrammar الأقدم من 0.1.18 الوصف: تتعلق المشكلة بوجود ذاكرة تخزين مؤقتة غير محدودة للقواعد النحوية المُجمَّعة في الذاكرة، وهو ما يمكن استغلاله للتسبب في هجوم «رفض الخدمة» (DoS) عن طريق ملء ذاكرة المضيف. وقد يحدث ذلك عندما يتلقى نظام يستخدم XGrammar العديد من الطلبات الصغيرة ذات مخططات JSON الفريدة، مثل إرسال طلبات متعددة إلى خادم استدلال نماذج اللغة الكبيرة (LLM). التوصيات: بالنسبة للإصدارات الأقدم من 0.1.18، قم بالتحديث إلى الإصدار 0.1.18 لحل المشكلة.

يحتوي vLLM، وهو محرك استدلال وتقديم للنماذج اللغوية الكبيرة (LLMs)، على مشكلة تتعلق بتنفيذ التعليمات البرمجية عن بُعد. ويؤثر ذلك على البيئات التي تستخدم تكامل نقل ذاكرة التخزين المؤقت KV `PyNcclPipe` مع محرك V0. تنشأ المشكلة من استخدام `pickle.loads` لمعالجة البيانات المقدمة من العميل ضمن تطبيق `PyNcclPipe`، مما يؤدي إلى ظهور ثغرة أمنية غير آمنة في عملية إزالة التسلسل. يمكن للمهاجم استغلال هذه الثغرة عن طريق إرسال بيانات متسلسلة ضارة للحصول على امتيازات التحكم في الخادم. تُستخدم فئة `PyNcclPipe` لإقامة اتصال نظير إلى نظير لنقل البيانات بين العقد الموزعة، ويتم تنفيذ نقل ذاكرة التخزين المؤقتة KV من جانب وحدة معالجة الرسومات (GPU) من خلال فئة `PyNcclCommunicator`. أما تمرير رسائل التحكم من جانب وحدة المعالجة المركزية (CPU) فيتم التعامل معه عبر طريقتي `send obj` و`recv obj`. كان السلوك المقصود هو أن تكون هذه الواجهة مكشوفة فقط لشبكة خاصة باستخدام عنوان IP المحدد بواسطة معلمة CLI `--kv-ip`. يسمح السلوك الافتراضي لـ PyTorch لواجهة `TCPStore` بالاستماع على جميع الواجهات، بغض النظر عن عنوان IP المقدم.

تتعلق المشكلة بمكتبة outlines التي يستخدمها vLLM للإخراج المنظم، والتي تحتوي على ذاكرة تخزين مؤقتة اختيارية لقواعد النحو المُجمَّعة في نظام الملفات المحلي. هذه الذاكرة المؤقتة مُفعَّلة بشكل افتراضي. يمكن لمستخدم ضار استغلال ذلك عن طريق إرسال طلبات فك تشفير قصيرة متعددة ذات مخططات فريدة، مما يؤدي إلى تضخم ذاكرة التخزين المؤقتة ويؤدي محتملًا إلى حدوث حالة «رفض الخدمة» (DoS) إذا نفد المساحة المتاحة في نظام الملفات. يقع الكود المتأثر في الملف vllm/model executor/guided decoding/outlines logits processors.py، الذي يستخدم ذاكرة التخزين المؤقتة الخاصة بـ «outlines» دون شروط. تنطبق المشكلة فقط على المحرك V0.