Кратко

  • RFC 3045 определила необязательные атрибуты vendorName и vendorVersion в root DSE LDAP-сервера: они позволяли показать, кто реализовал сервер, или распознать возможную программную аномалию.
  • Документ запретил использовать эти строки для обнаружения возможностей. Заявленные производитель и версия не удостоверяли происхождение программы и не доказывали работу функции на конкретном сервере или в данной сессии.

Клиент LDAP уже мог читать корневую DSA-specific Entry, или root DSE, чтобы получить сведения о сервере, к которому он подключился. RFC 3045 добавила к такому ответу два возможных ориентира: vendorName и vendorVersion. Опубликованная в январе 2001 года информационная RFC разрешала серверу сообщить имя разработчика и указанную им версию продукта. Это были операционные атрибуты с одним значением, а не обычные поля каталога, доступные для изменения его пользователям.

Область применения была намеренно узкой. Клиент мог показать производитель и версию оператору или распознать выпуск, связанный с известной аномалией, а затем рассмотреть обходной приём. Но RFC 3045 запрещала извлекать из этих значений сведения о поддерживаемых функциях. Название производителя не говорит, какие элементы управления, расширения или механизмы примет конкретный сервер. Версия не показывает, включена ли функция в текущей конфигурации, доступна ли текущей аутентифицированной сессии и работает ли она на деле. Возможности следовало объявлять механизмами, предусмотренными для каждой конкретной функции.

Это ограничение отсекало соблазнительный, но ненадёжный короткий путь. Если клиент считал «производитель X, версия Y» согласованием возможностей, он мог обойти протокольные свидетельства, разработанные для самой функции. В результате клиент мог вызвать неподдерживаемую операцию или отказаться от доступной. RFC 3045 позволяла использовать имя продукта для контекста, но не вместо наблюдаемого результата.

Даже формат версии был устроен против ложной точности. RFC требовала, чтобы значения vendorVersion различались между версиями, но не задавала синтаксиса или порядка. Сопоставление было на равенство, не «меньше» или «больше». Выбирая обход для известной аномалии, клиент должен был точно совпасть со строкой, связанной с ней, а не решать самостоятельно, что 8.01 старше или младше 8.5. Название версии — это имя, а не обязательно сопоставимое число.

И точное совпадение не давало полной картины реализации. RFC 3045 отмечала, что аномалия могла затронуть только часть серверов с одной и той же заявленной версией: платформы, настройки и плагины различаются. Документ также предупреждал, что указанное имя или версия не гарантируют, будто сервер действительно создан этим производителем или работает именно на таком выпуске. Атрибут доказывает только то, что сообщил сервер, но не подлинность двоичного файла и не всё его поведение.

Атрибуты были необязательными. Сервер мог ограничить доступ к ним, и клиент не должен был рассчитывать на их наличие. Отсутствие сведений не означает неисправность сервера и не исключает совместную работу. Информация, полезная при диагностике, может открыть атакующему детали программного обеспечения; RFC 3045 прямо предупреждала, что название производителя и версия могут помочь обнаружить уязвимость.

В последующих LDAP-спецификациях различие между идентичностью и возможностями сохранилось. RFC 4512 описывает root DSE как собственную для каждого сервера операционную запись и отдельно перечисляет supportedControl, supportedExtension и supportedFeatures; их значения могут зависеть от условий сессии. В нынешнем реестре параметров LDAP IANA по-прежнему перечислены OID атрибутов vendorName и vendorVersion. Это подтверждает выделение идентификаторов, но не достоверность чьего-либо заявления и не поддержку функции. Урок RFC 3045 — разделение обязанностей: метка помогает понять контекст, а конкретные данные о функции показывают, что реально доступно соединению.

Источники