REDHAT-BUG-2529332: Medium severity 389 Project 389-ds-base vulnerability
A flaw was found in 389-ds-base. When a client negotiates StartTLS, the server (starttlsioenable() in starttlsextop.c) replaces the connection's underlying socket with a TLS-wrapped one but does not discard or invalidate plaintext bytes already buffered from the socket (cbufferbytes/cbufferoffset in connection.c), which are otherwise only reset on a BER parse error or after a fresh read -- neither of which occurs during the StartTLS transport switch. An on-path (man-in-the-middle) attacker can place a second LDAP message in the same TCP segment as the client's StartTLS request; after the server switches to TLS, it parses this smuggled message out of the stale plaintext buffer (openldapreadfunction() in connection.c serves bytes from cbuffer regardless of which underlying descriptor is active) and writes the response inside the new TLS session. By stamping the smuggled message with the messageID the client's next operation (its bind) will use, the attacker's smuggled BindResponse (e.g. an anonymous bind, which always succeeds) is delivered to the client in place of the real bind response, which the connection's turbo-mode single-operation guard does not catch because the smuggled bytes are not yet a tracked Operation object. This causes the client to believe an authentication attempt succeeded when the directory actually rejected it. The default configuration is affected (nsslapd-connection-buffer defaults on; nsslapd-minssf defaults to 0); no misconfiguration is required. Independently reproduced against the real, shipping 389-ds-base-2.6.1-6.el96 build: a wrong-password LDAP bind is forged into a reported success, and separately, using a custom PAM test harness exercising the real pamauthenticate/pamacctmgmt/pamopensession lifecycle against real libldap, a full PAM login session is opened for an existing account with a definitively wrong password. Server-side, 389-ds-base itself suffers no privilege escalation or data exfiltration -- the attacker's own smuggled operation runs anonymous and the client's own subsequent (failing) bind resets the connection to anonymous immediately after. The impact is realized entirely in client-side applications that trust the LDAP bind result (e.g. PAM/nss-pam-ldapd), and the affected clients are not required to have any particular parsing flaw of their own -- both a smuggled BindRequest (any LDAP client) and, per a related but separately-reported OpenLDAP client issue, a smuggled SearchRequest are viable. StartTLS on port 389 is affected; ldaps:// (636) has no cleartext prefix and is not affected.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Use LDAPS (ldaps:// on port 636) instead of StartTLS on port 389; LDAPS has no cleartext prefix and is not affected.
Event History
Frequently Asked Questions
What access does an attacker need to exploit this issue?
The attacker must be on path between the LDAP client and server and able to inject an additional LDAP message in the same TCP segment as the client's StartTLS request.
When does the injected message get processed?
It is processed after the server switches to TLS because plaintext bytes buffered before the transport change are not discarded or invalidated. The server can then send the response to that injected message inside the TLS session.
What client operation can be affected by the response substitution?
An attacker can use the message ID expected for the client's next operation, such as a bind. The description specifically notes that an anonymous-bind response can be delivered to the client in place of the real bind response.