389 Directory Server's SELFDN ACI bind-rule evaluator (ldap/servers/plugins/acl/acllas.c) compares a client's bind DN against a stored attribute value using a plain string comparison. An anonymous LDAP bind has an empty-string client DN, and 389-ds's own DN syntax validator (ldap/servers/plugins/syntaxes/dn.c) accepts zero-length attribute values as valid. As a result, any ACI written as userattr="X#SELFDN", where attribute X can legitimately hold an empty value, is satisfied by an anonymous client with no authentication of any kind.

This was originally reported (PSIRTSUPT-21812) as part of a FreeIPA-specific admin-takeover chain, but independently reproduced standalone against plain 389-ds-base (389-ds-base-3.2.2-2.fc44) with zero FreeIPA schema, plugins, or ACIs present: a minimal test ACI (allow (add) userattr = "owner#SELFDN") was defeated by an anonymous bind with owner: set to an empty value, while a control case (non-empty, non-matching value) was correctly refused. This confirms the defect is general to the ACI evaluation engine, not specific to any consuming application.

Any 389-ds/RHDS deployment that defines a SELFDN-based ACI on an attribute permitted to hold an empty value is affected. Reported and confirmed as part of the PSIRTSUPT-21812 investigation; see linked Jira ticket for full technical writeup and reproduction evidence.

A flaw was found in 389 Directory Server. The opsharedsearch function in opshared.c does not check for a NULL backend pointer when reusing a paged-results slot in the bename (USEONEBACKEND control) code path. An unauthenticated client can exploit this by sending two SEARCH requests on the same connection: the first names a non-existent backend via the USEONEBACKEND control with a Simple Paged Results (SPR) empty cookie, storing NULL as the backend in a paged-results slot; the second names a valid backend with an SPR cookie referencing that slot, causing the server to retrieve the stored NULL and call slapibeRlock(NULL), which dereferences the NULL pointer and crashes the ns-slapd process. This is reachable pre-authentication because control and paged-results processing runs before search authorization. Paged results and anonymous access are both enabled by default.

A flaw was found in 389 Directory Server. The PBKDF2-SHA256 password verification function pbkdf2sha256pwcmp() in ldap/servers/plugins/pwdstorage/pbkdf2pwd.c uses standard memcmp() for hash comparison instead of the project's constant-time slapictmemcmp(). Every other password storage scheme in the same plugin uses slapictmemcmp(), which was introduced specifically to prevent timing side-channels (see CVE-2016-5405). This inconsistency allows a remote attacker with network access to the LDAP service to potentially infer partial hash information through repeated timing measurements of LDAP bind attempts. Practical exploitation is extremely difficult due to the PBKDF2 work factor (8192+ iterations, ~2ms computation time) which dominates and masks the nanosecond-level memcmp timing delta.