REDHAT-BUG-2561778: Medium severity 389 Project 389-ds-base vulnerability
A flaw was found in 389-ds-base. When processing a ModifyDN (rename) request whose new relative distinguished name (RDN) uses an attribute's schema alias name (for example, "commonName") instead of its canonical name (for example, "cn"), the server fails to recognize that the aliased attribute already exists on the target entry. This causes the directory server to construct a duplicate, inconsistent internal attribute structure for the entry. A subsequent internal lookup against this inconsistent structure dereferences a NULL pointer, crashing the ns-slapd process. An authenticated user holding the "moddn" (rename) access control right on an entry can use this flaw to crash the directory server, resulting in a denial of service for all users of that directory server instance.
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
An authenticated user must have the "moddn" (rename) access control right on the targeted directory entry. Users without that permission are not described as able to trigger the flaw.
What request is required to trigger the crash?
The user must submit a ModifyDN rename request whose new RDN uses a schema alias attribute name, such as "commonName," rather than the attribute's canonical name, such as "cn." The aliased attribute must already exist on the target entry.
What is the operational impact if exploitation succeeds?
The malformed internal attribute structure causes a later internal lookup to dereference a NULL pointer and crash the ns-slapd process. This results in denial of service for all users of the affected directory server instance.
What can be restricted while a fix is unavailable?
Limit the "moddn" rename access control right to only trusted accounts that require it. This reduces the set of authenticated users able to submit the triggering ModifyDN request.