Zusammenfassung

  • RFC 3045 definierte die optionalen Attribute vendorName und vendorVersion im Root DSE eines LDAP-Servers, damit Implementierer angezeigt oder mögliche Softwareanomalien erkannt werden konnten.
  • Zugleich verbot sie, diese Zeichenketten zur Funktionssuche zu verwenden. Der selbst gemeldete Hersteller und die Versionsangabe authentifizierten weder die Herkunft der Software noch den Betrieb einer Fähigkeit auf diesem Server oder in dieser Sitzung.

Ein LDAP-Client konnte bereits das Root DSA-specific Entry, kurz Root DSE, auslesen, um Informationen über den konkreten Server zu erhalten, mit dem er verbunden war. RFC 3045 ergänzte dafür zwei mögliche Hinweise: vendorName und vendorVersion. Die im Januar 2001 veröffentlichte Informational RFC erlaubte dem Server, den Implementierer und eine Versionszeichenkette anzugeben. Beide Attribute waren einwertige Betriebsattribute und keine gewöhnlichen Felder, die ein Verzeichnisnutzer ändern konnte.

Der vorgesehene Zweck war bewusst eng. Ein Client durfte Hersteller und Version für den Betreiber anzeigen oder eine Version erkennen, die mit einer bekannten Anomalie verbunden war, und eine Umgehung erwägen. RFC 3045 untersagte aber, aus denselben Werten unterstützte Funktionen abzuleiten. Der Herstellername verrät nicht, welche Controls, Erweiterungen oder Mechanismen eine konkrete Instanz akzeptiert. Die Versionszeichenkette sagt nicht, ob eine Funktion in dieser Konfiguration aktiviert, für diese authentifizierte Sitzung verfügbar oder tatsächlich funktionsfähig ist.

Fähigkeiten sollten über Mechanismen angekündigt werden, die für die jeweilige Fähigkeit vorgesehen sind.

Diese Grenze verhinderte eine verlockende, aber brüchige Abkürzung. Wer „Hersteller X, Version Y“ als Aushandlung von Fähigkeiten behandelt, kann die Protokollbelege umgehen, die für eine Funktion vorgesehen sind. Dann würde der Client vielleicht eine nicht unterstützte Operation starten oder eine verfügbare Funktion verwerfen. RFC 3045 ließ die Produktidentität den Befund einordnen, aber nicht den Befund ersetzen.

Auch die Versionsregel sollte Scheingenauigkeit vermeiden. Der Wert von vendorVersion musste zwischen Versionen eindeutig sein, doch RFC 3045 schrieb weder Syntax noch Reihenfolge vor. Verglichen wurde auf Gleichheit, nicht mit „kleiner“ oder „größer“. Für eine bekannte Fehlerumgehung sollte der Client genau die zugehörige Zeichenkette abgleichen, statt zu unterstellen, 8.01 liege vor oder nach 8.5. Versionsbezeichnungen sind Namen, nicht notwendigerweise vergleichbare Zahlen.

Selbst eine exakte Übereinstimmung beschrieb nicht die gesamte Implementierung. RFC 3045 wies darauf hin, dass eine Anomalie nur einen Teil der Server mit derselben Versionsangabe betreffen kann: Plattformen, Konfiguration und Plug-ins unterscheiden sich. Außerdem garantiert ein zurückgegebener Name oder eine Versionsangabe nicht, dass der Server tatsächlich von diesem Hersteller stammt oder genau diese Version ausführt. Das Attribut belegt, was der Server meldet, nicht die Echtheit seines Binärprogramms oder sein gesamtes Verhalten.

Die Attribute waren außerdem optional. Server durften den Zugriff beschränken; Clients sollten nicht mit ihrer Verfügbarkeit rechnen. Wenn sie fehlen, ist der Server nicht automatisch defekt, und Interoperabilität ist nicht ausgeschlossen. Was bei der Fehlersuche hilft, kann einem Angreifer zugleich Softwaredetails verraten. RFC 3045 nannte ausdrücklich das Risiko, dass Hersteller- und Versionsangaben beim Auffinden einer Schwachstelle helfen können.

Auch die spätere LDAP-Architektur hielt Identität und Fähigkeit auseinander. RFC 4512 beschreibt das Root DSE als serverindividuellen Betriebsdatensatz und nennt eigene Attribute wie supportedControl, supportedExtension und supportedFeatures, deren Werte von der Sitzung abhängen können. Das aktuelle IANA-Register für LDAP-Parameter führt die OIDs für vendorName und vendorVersion weiterhin; damit sind die Kennungen bestätigt, nicht die Aussagen eines Servers oder seine Fähigkeiten. RFC 3045 verteilt die Rollen: Labels helfen beim Einordnen, funktionsspezifische Belege zeigen, was eine Verbindung tatsächlich nutzen kann.

Quellen