OpenBSD ldapd authentication result mix-up enables Bind as another identity

In ldapd in OpenBSD 7.8 before errata 057 and 7.9 before errata 021, delegated BSD authentication results are correlated only by the LDAP child process client file descriptor and LDAP message ID. After a connection closes, a later connection that reuses the same file descriptor and message ID can receive the earlier authentication result. A remote attacker who can reach ldapd can complete a Bind as another identity. A missing connection can also cause a NULL pointer dereference. (ldapd is not enabled by default.)

• OpenBSD 7.8: affected before errata 057. The corresponding errata is 057_ldapd.patch.sig. • OpenBSD 7.9: affected before errata 021. The corresponding errata is 021_ldapd.patch.sig. • ldapd is not enabled by default. The status of other branches or releases is not established by the reviewed evidence, so they should not be assumed to be covered or unaffected.

The flaw is in how ldapd delegates BSD authentication to an LDAP child process and correlates the returned result with the pending Bind request. Before the fix, correlation used only the LDAP child process client file descriptor and the LDAP message ID. After a connection closes, its file descriptor can be reused by a later connection; if the message ID is also reused, the earlier authentication result can be applied to the later connection, creating an Incorrect Authorization condition classified as CWE-863.

The fix assigns each connection a unique 64-bit identifier, carries that identifier in authentication requests and results, and looks up connections with conn_by_id instead of conn_by_fd. It also checks for a missing connection before continuing to process the result, preventing a NULL pointer dereference. The publicly documented material does not fully establish the exact packet ordering, connection timing, or message ID conditions needed to reproduce every exploitable case.

The flaw is remotely reachable by an attacker who can access the ldapd service. The supplied assessment indicates that no prior privileges or user interaction are required, but the attack has high complexity and depends on conditions involving connection and message ID reuse. The outcome can be completion of an LDAP Bind as another identity; a separate processing path can trigger a NULL pointer dereference. The record and inspected source materials do not identify a public exploit, exploitation campaign, or named victim; that does not prove that exploitation has never occurred.

The flaw can cause a successful authentication result from one transaction to be applied to another transaction, producing authentication under the wrong identity and bypassing access controls within that identity's permissions. The attacker does not need prior credentials according to the supplied assessment, but must reach ldapd and satisfy the high-complexity connection, file descriptor, and message ID conditions. If the referenced connection is no longer present when the result is handled, ldapd can encounter a NULL pointer dereference and lose service availability. The record does not establish that every LDAP configuration or Bind flow is exploitable, so the practical impact depends on use of delegated BSD authentication and the privileges assigned to LDAP identities.

• A remote user may be authenticated as a different identity, potentially bypassing LDAP-based access decisions when the result-matching condition occurs. • Read or write operations authorized for the misidentified account could expose or alter data, depending on that account's ACLs and effective privileges. • The NULL pointer dereference can stop ldapd or make it unable to provide authentication, disrupting logins and dependent services. • The exposure is limited to deployments that enable and make ldapd reachable; systems that do not run the daemon are not described as exposed to this mechanism.

1. Prioritize the official errata for the deployed branch: errata 057 for OpenBSD 7.8 or errata 021 for OpenBSD 7.9.
2. Verify the corresponding patch signature with the matching base key before applying it. The official patch instructions apply the patch to the source tree and then rebuild and install ldapd.
3. After applying the patch, repeat the documented make obj, make and make install process in usr.sbin/ldapd.
4. If ldapd is not required, keep the daemon disabled and restrict network reachability to it as a temporary risk-reduction measure.
5. Recheck the daemon and dependent services after updating, and confirm that the running build contains the change that uses a per-connection identifier instead of the socket file descriptor.

1. Inventory OpenBSD hosts that have ldapd installed or running. Because the service is not enabled by default, check both startup configuration and the active process state.
2. Determine the release branch and errata state for each host, then compare them with the affected boundaries in affected_summary.
3. For source-built systems, verify that ldapd assigns a 64-bit connection identifier, uses conn_by_id, and handles a result for a connection that no longer exists.
4. Review ldapd logs for auth result with no connection or spurious auth result. These are diagnostic messages present in the fixed code, not confirmed indicators of compromise; their absence does not prove that a system is safe.
5. As an additional precaution, review anomalous Bind events where the authentication result does not match the connection or identity recorded by the LDAP-consuming application.