REDHAT-BUG-2489835: Buffer Overflow

Three related heap buffer overflow bugs were found in the aclpnormalizeacltxt() function in ldap/servers/plugins/acl/aclparse.c of 389 Directory Server. The function is called during ACI (Access Control Instruction) parsing via aclparse() -> aclpparseaci() -> aclpsanitycheckacltxt() -> aclpnormalizeacltxt().

The root cause is that aclpnormalizeacltxt() blindly assumes the ACI string after whitespace stripping still has at least 3 characters (the "aci" or "acl" keyword), without any bounds check. The assert(s) on line 850 only checks for NULL, not for an empty or too-short string, and asserts are compiled out in release builds (NDEBUG).

The three bugs are:

1. Out-of-bounds WRITE (1 byte): On line 852, (s + 2) = 'l' writes one byte past the heap buffer when the string is too short after whitespace stripping.

2. Out-of-bounds READ (strchr): On line 856, strchr(aclstr, ';') reads past the buffer because the NUL terminator was clobbered or the string lacks a semicolon.

3. Out-of-bounds READ (strdup): On line 866, slapichstrdup(aclName) reads past the buffer in strdup for the same root cause.

To trigger the vulnerability, an attacker needs write access to the 'aci' attribute on a directory entry. In the default modern configuration (389-ds-base 2.x / RHDS 12), only the Directory Manager can write ACIs. However, in older deployments or those using common ACI patterns with negated targetattr rules (e.g., targetattr!="userPassword") or wildcards (targetattr=""), any authenticated user may be able to write to the 'aci' attribute.

ASAN is not enabled in production release builds (the spec file defaults to %bcond asan 0 / %global useasan 0). In production binaries, the heap corruption is silent — the 1-byte write corrupts adjacent heap memory without a deterministic crash, and the OOB reads silently read garbage from adjacent heap allocations. The practical impact in production builds is likely negligible, making this primarily a hardening issue.

The 1-byte write primitive is not controllable (fixed value 'l'/0x6C at fixed offset +2 from a small allocation) and is not realistically weaponizable for code execution.

Upstream fix: https://github.com/389ds/389-ds-base/pull/7542 Upstream issue: https://github.com/389ds/389-ds-base/issues/7541