الخلاصة

  • عرّفت RFC 3045 السمتين الاختياريتين vendorName وvendorVersion في root DSE لخادم LDAP، لتوضيح الجهة المنفذة أو المساعدة في التعرّف على خلل برمجي محتمل.
  • منعت استخدام هاتين السلسلتين لاكتشاف الوظائف المدعومة. فاسم المورّد والإصدار المعلنان لا يثبتان مصدر البرنامج ولا أن قدرة ما تعمل على ذلك الخادم أو في تلك الجلسة.

كان بإمكان عميل LDAP قراءة مدخل DSA-specific Entry الجذري، المعروف باسم root DSE، لمعرفة معلومات خاصة بالخادم الذي اتصل به. وأضافت RFC 3045 إلى هذا الرد مؤشرين محتملين: vendorName وvendorVersion. وسمحت هذه الوثيقة المعلوماتية، المنشورة في يناير 2001، للخادم بالإعلان عن الجهة التي نفذت البرنامج وعن سلسلة الإصدار التي يذكرها. وهما سمتان تشغيليتان أحاديتا القيمة، لا حقولاً عادية يستطيع مستخدم الدليل تعديلها.

كان الاستخدام المقترح محدوداً عن قصد. يستطيع العميل عرض المورّد والإصدار لمسؤول النظام، أو التعرّف على إصدار ارتبط بخلل معروف ثم النظر في إجراء التفافي. لكن RFC 3045 منعت استخدام القيمتين لاستنتاج الوظائف المدعومة. لا يكشف اسم المورّد أي عناصر تحكم أو امتدادات أو آليات يقبلها خادم بعينه. كما لا يبين رقم الإصدار إن كانت وظيفة ما مفعّلة في الإعداد الحالي، أو متاحة للجلسة المصادق عليها، أو تعمل فعلاً. ينبغي إعلان القدرات من خلال آليات مصممة للقدرة المعنية.

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

حتى مقارنة الإصدار صيغت لتجنب الدقة الزائفة. اشترطت RFC أن تكون قيمة vendorVersion فريدة بين الإصدارات، لكنها لم تفرض صيغة أو ترتيباً رقمياً. وكانت المطابقة بالمساواة، لا بعلاقة «أقل من» أو «أكبر من». فإذا اختار العميل إجراءً لتجاوز خلل، فعليه مطابقة السلسلة المرتبطة به كما هي، لا أن يفترض أن 8.01 أقدم من 8.5 أو أحدث منها. أسماء إصدارات المنتجات ليست بالضرورة أرقاماً قابلة للترتيب.

وحتى التطابق التام لا يصف التنفيذ كله. أشارت RFC 3045 إلى أن الخلل قد يصيب بعض الخوادم فقط رغم إعلانها الإصدار نفسه؛ فالمنصات وخيارات الإعداد والإضافات تختلف. وحذرت أيضاً من أن الاسم أو الإصدار المعاد لا يضمن أن الخادم بُني فعلاً لدى المورّد المذكور أو أنه يشغّل الإصدار المعلن. ما تثبته السمة هو ما أعلنه الخادم، لا هوية الملف التنفيذي ولا مجمل سلوكه.

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

أبقت بنية LDAP اللاحقة الفصل بين الهوية والقدرة واضحاً. تصف RFC 4512 root DSE بأنه مدخل تشغيلي خاص بكل خادم، وتعدد سمات مستقلة مثل supportedControl وsupportedExtension وsupportedFeatures؛ وقد تتغير قيمها بحسب الجلسة. ما زال سجل IANA لمعاملات LDAP يسرد معرّفي OID الخاصين بـvendorName وvendorVersion، لكن ذلك يثبت تخصيص الأرقام لا صحة أي ادعاء خادمي ولا قدراته. ودرس RFC 3045 هو توزيع الأدوار: تساعد الملصقات على فهم السياق، أما دليل كل قدرة فيحدد ما يمكن للاتصال استخدامه فعلاً.

المصادر