REDHAT-BUG-2519521: High severity 389 Project 389 Directory Server vulnerability
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.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed?
Any 389 Directory Server or RHDS deployment that defines a SELFDN-based ACI using an attribute that is permitted to contain an empty value may be exposed. The issue was reproduced in plain 389-ds-base without FreeIPA schema, plugins, or pre-existing ACIs, so it is not limited to FreeIPA deployments.
What does an attacker need to exploit this?
An attacker needs only an anonymous LDAP bind when an applicable ACI uses the userattr="X#SELFDN" form and the relevant attribute X has an empty value. No authentication is required because the anonymous client's bind DN is an empty string.
Are installations affected by default?
The standalone reproduction required adding a minimal SELFDN-based ACI; the test server had no pre-existing ACIs. Exposure therefore depends on deployed ACI configuration rather than on FreeIPA components or schema being present.
How can I identify potentially affected access controls?
Review ACIs for SELFDN user-attribute rules such as userattr="owner#SELFDN". Determine whether the referenced attribute can be set to an empty value and whether anonymous LDAP binds can reach operations authorized by that ACI.