A flaw was found in 389 Directory Server. The LDAP extended-operation handlers that start (multisupplierextopcleanruv) and abort (multisupplierextopabortcleanruv) the CleanAllRUV replication-maintenance task in ldap/servers/plugins/replication/replextop.c perform no check on the connection's bind DN or authentication state, unlike the analogous multisupplierextopStartNSDS50ReplicationRequest handler in the same file, which explicitly verifies the connection is an authorized replication updatedn via replicaisupdatedn(). Under the default nsslapd-allow-anonymous-access configuration, a fully anonymous network client that can reach a supplier's LDAP listener and knows the target suffix and replica ID can start or abort CleanAllRUV; if anonymous access has been restricted, any client that has completed a successful bind (regardless of privilege level) can do the same, since the handlers themselves perform no further authorization check. This lets the client cause unauthorized removal of a replica ID from replication metadata, purge related changelog records, and interrupt administrator-initiated cleanup operations, potentially leaving replication inconsistent or unavailable. Reported by Andrew Rukin (Arenadata), who verified the issue against 389-ds-base-3.3.0-5.fc45.x8664 with both a single supplier and two replicating suppliers, and confirmed the abort handler likewise lacks the check by source review. Independently reproduced live in an isolated sandbox against the same NVR: the anonymous start request was accepted and genuinely executed (RUV entry removed, changelog purged), a well-formed request to the sibling, protected StartNSDS50ReplicationRequest handler was correctly rejected under the same unauthenticated precondition, and cross-supplier propagation was confirmed (a second supplier independently completed the identical cleanup via its replication agreement with the targeted supplier, without ever receiving a direct request from the client).

A denial of service vulnerability was found in 389-ds-base ldap server. This issue may allow an authenticated user to cause a server crash or hang while authenticating with an user having a malformed userPassword. By default only the administrator may directly add hashed password that can trigger the issue. But if nsslapd-allow-hashed-passwords config parameter is turned on, any user can trigger the issue.

The problem is triggered by adding a password to an user using the hashed format (with a hash value too long for the specified hash scheme) Then later on when trying to authenticate on that user its triggers the buffer overflow

By default, only administrators are allowed to add hashed passwords but there is a configuration parameter (nsslapd-allow-hashed-passwords) allowing any users to add hashed passwords and potentially trigger the DoS.

This vulnerability affects versions: >= 1.3.7.2

A vulnerability was found in 389-ds-base : the deref plugin is checking for either READ or SEARCH permission for dereferencing an attribute. This means that the SEARCH permission is sufficient to display an attribute via the plugin.

This is relevant in particular in IdM/IPA environment, where a default ACI ("Search existence of password and kerberos keys") in set. This leads to dereferencing able to display userPassword content or any users.

A vulnerability in 389-ds-base was found that allows to bypass limitations for compare and read operations specified by Access Control Instructions.

When having LDAP sub-tree with some existing objects and having BIND DN which have no privileges over objects inside the sub-tree, unprivileged user can send LDAP ADD operation specifying an object in (supposedly) inaccessible sub-tree. The returned error messages discloses the information when the queried object exists having the specified value. Attacker can use this flaw to guess values of RDN component by repeating the above process.

Upstream commit:

https://github.com/389ds/389-ds-base/commit/0b932d4b926d46ac5060f02617330dc444e06da1

Kurt Seifried of Red Hat Product Security reports:

There are several temporary file creation vulnerabilities:

In the file

./389-admin-1.1.36/admserv/newinst/src/AdminServer.pm.in

my $secfilebackupdir = "/tmp/adm-sec-files." . $$;

and in the file:

./389-admin-1.1.36/lib/libadmin/httpcon.c

char dbd = "/tmp/httptrace.%d";

The perl code should use mkstemp() and the C code should use mkstemp().

These issues are only locally exploitable and require administrative action in order to exploit.