llm 0.37.2 يغلق تسريبًا: مفتاح OpenAI كان قد يصل إلى مزوّد خارجي

أصبحت أداة llm من سايمون ويليسون منذ زمن طويل بمثابة سكين سويسري للعديد من المطورين للتعامل مع النماذج اللغوية من الطرفية. فهي لا تتصل بـ OpenAI فحسب، بل بأي مزوّد يوفّر واجهة API متوافقة مع OpenAI. ومن هذه المرونة تحديدًا ظهرت المشكلة: ففي الإصدار 0.37.2 أُغلقت ثغرة كانت تتيح إرسال مفتاح OpenAI السري إلى جهة غير المقصودة.

ماذا حدث

تتضمن llm آلية لربط نقاط نهاية خارجية عبر الملف extra-openai-models.yaml. ومنذ الإصدار 0.37 تتولى إدارتها أمر مستقل هو llm openai endpoint add. الفكرة بسيطة: كثير من المزوّدين والخوادم المحلية يحاكون صيغة واجهة OpenAI، لذا يمكن وصفهم في ملف الإعداد والتعامل معهم كنماذج عادية.

اكتشف الباحث Daniel de Araujo حالتين كان يمكن فيهما أن يصل مفتاح OpenAI الخاص بك إلى نقطة نهاية خارجية كهذه. وقد نُشرت توصيتان أمنيتان على GitHub بهذا الشأن: GHSA-v9h7-jj4g-f862 وGHSA-r639-rr7r-x72w.

• المفتاح المحدد في api_key_name لم يكن محفوظًا. بالنسبة لنقطة نهاية خارجية، تحدد الاسم الذي يُخزَّن تحته مفتاحها. وإذا لم يُحفظ هذا المفتاح قط، فلا ينبغي للأداة أن تستبدله بأي مفتاح آخر. ووفق وصف الثغرة، كانت تستخدم مفتاح OpenAI المُعدّ.
• شُغّل نموذج بالإعداد responses: true مع -o chat_completions 1. كان هذا الدمج يحوّل الطلب إلى نمط عمل مختلف، وقد يذهب المفتاح أيضًا إلى جهة خاطئة.

في الحالتين لا حاجة لأي نية خبيثة. يكفي أن تنسى إضافة المفتاح أو أن تمرر خيارًا، فيصبح السر بيد طرف ثالث.

لماذا هذا مزعج

تخيّل إعدادًا نموذجيًا. لديك في llm مفتاح OpenAI محفوظ لمهام العمل. وربطت نقطة نهاية لمزوّد صغير أو وسيط خارجي لمقارنة النماذج. كتبت اسم المفتاح في ملف الإعداد، لكنك لم تتمكن من إضافة المفتاح نفسه. تشغّل الأمر، فينطلق الطلب حاملًا مفتاح OpenAI الخاص بك إلى خادم لا تتحكم فيه.

عندها يصبح لدى هذا المزوّد مفتاح عامل مرتبط بحدّك وفوترتك. وأي نقطة نهاية خارجية، خصوصًا المصنوعة يدويًا أو التجريبية، قد تسجّله. إنه تسريب عادي لسر بسبب خطأ في الإعداد، وليس هجومًا غريبًا.

ما العمل

1. التحديث إلى llm 0.37.2. هذه هي الخطوة الأساسية، وهي تغلق السيناريوهين.
2. فتح extra-openai-models.yaml ومراجعة نقاط النهاية الموصوفة فيه. تأكد من أن لكل منها api_key_name محددًا وأن المفتاح المقابل محفوظ فعلًا.
3. تذكّر ما إذا كنت قد شغّلت نماذج بالإعداد responses: true مع -o chat_completions 1. إذا كان الأمر كذلك وكانت نقطة النهاية لا تتبع OpenAI، فالأفضل اعتبار المفتاح مخترقًا.
4. عند أدنى شك، أعد إصدار مفتاح OpenAI. فهذا رخيص، ولا داعي لمخاطرة زائدة.

وهناك درس عام أيضًا. يجب فصل مفاتيح المزوّدين المختلفين فصلًا صارمًا. وإذا كانت لديك عدة نقاط نهاية، فلا ينبغي أن يكون مفتاح OpenAI هو القيمة التي تستخدمها الأداة افتراضيًا. ومن المنطقي إنشاء مفاتيح منفصلة بحدود مقيّدة لتجارب واجهات API الخارجية.

القيود

لا تتضمن ملاحظة الإصدار تفاصيل عن كيفية استغلال الثغرة، ولا بيانات عن حالات تسريب فعلية. ويصف المؤلف المشكلة بأنها إرسال عرضي للمفتاح، وليست هجومًا يمكن تنفيذه عن بُعد. وهذا يخفف من حدّتها، لكنه لا يلغي ضرورة التحديث: فأخطاء الإعداد تحدث للجميع.

ويظهر صنف مشابه من الأخطاء في أدوات أخرى يعمل فيها عميل واحد مع عدة مزوّدين. وكل ما يقبل عنوانًا «متوافقًا مع OpenAI» ويحتفظ في الوقت نفسه بمفتاح OpenAI يستحق الفحص للسلوك نفسه: ماذا يُستخدم عندما لا يُعثر على مفتاح لذلك العنوان؟

الخلاصة العملية

إذا كنت تستخدم llm مع OpenAI فقط، فهذا لا يعنيك تقريبًا. أما إذا ربطت نقاط نهاية خارجية، فحدّث الآن وراجع ملف الإعداد. وعند أي تركيبة مشبوهة من الخيارات، أعد إصدار المفتاح.