Bug 2529450

Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.

389 Directory Server's 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 (slapi_utf8casecmp). 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. Where this comparison is reached with the target attribute holding an explicit empty value, an anonymous client's empty DN matches it and satisfies the bind rule with no authentication of any kind.

Independently reproduced and confirmed for two distinct bind-rule/operation combinations:

1. SELFDN on ADD: a minimal test ACI (allow (add) userattr = "owner#SELFDN") on plain 389-ds-base (389-ds-base-3.2.2-2.fc44), zero FreeIPA schema/plugins, was defeated by an anonymous ADD with owner: set to an empty value, while a control case (non-empty, non-matching value) was correctly refused.

2. USERDN on MODIFY: a minimal test ACI (allow (write) userattr = "owner#USERDN") was defeated by an anonymous MODIFY of a protected attribute once the target entry's owner attribute was set to an explicit empty value (not merely absent -- an absent attribute does not trigger the defect, confirmed by direct testing of both cases). A baseline case with owner holding a real, non-matching DN was correctly refused. Root cause confirmed at the code level in DS_LASUserDnAttrEval: userattr="...#USERDN" is explicitly excluded from the SELFDN-only ADD-time fast path in acllas.c, but on MODIFY the evaluator reads the stored attribute value via slapi_entry_attr_find and compares it to the client DN via slapi_utf8casecmp -- an empty stored value matches an anonymous bind's empty DN and access is granted (confirmed via ACL debug trace: "matches(, ) ... allowed by aci").

This confirms the defect is a general logic error in the ACI bind-rule evaluator itself, not limited to one bind-rule type (SELFDN) or one operation type (ADD) -- it reproduces for both SELFDN+ADD and USERDN+MODIFY. Any 389-ds/RHDS deployment defining a userattr="X#SELFDN" or userattr="X#USERDN" bind rule on an attribute permitted to hold an explicit empty value is affected.

Note: FreeIPA ships a default ACI of exactly this vulnerable shape (install/share/default-aci.ldif: "Allow member managers to modify members of user groups", gating write access to the "member" attribute of ipaUserGroup entries via userattr = "memberManager#USERDN" or userattr = "memberManager#GROUPDN"). Whether this specific ACI is exploitable in practice depends on whether any FreeIPA workflow ever sets memberManager to an explicit empty string rather than deleting the attribute outright when a member manager is removed -- that is a FreeIPA-code-level question, not yet confirmed, and is tracked separately from this 389-ds-level defect.