It was discovered that 398 / Red Hat Directory Server set LDLIBRARYPATH environment variable to insecure value containing empty path elements in various shell scripts used by DS (e.g. various backup/restore scripts instantiated for each DS instance, as well as the main initialization script). Such LDLIBRARYPATH setting causes ld.so dynamic linker to perform library search relative to the current working directory before searching system library directories. A local attacker able to trick a user running those scripts (usually the root user) to run them while working from an attacker writeable directory could use this flaw to escalate their privileges via specially crated dynamic library.

slapd (aka ns-slapd) in 389 Directory Server before 1.2.8.a2 does not properly manage the ctimelimit field of the connection table element, which allows remote attackers to cause a denial of service (daemon outage) via Simple Paged Results connections, as demonstrated by using multiple processes to replay TCP sessions, a different vulnerability than CVE-2011-0019.

IssueDescription:

It was found that when replication was enabled for each attribute in Red Hat Directory Server / 389 Directory Server, which is the default configuration, the server returned replicated metadata when the directory was searched while debugging was enabled. A remote attacker could use this flaw to disclose potentially sensitive information.

Acknowledgements:

This issue was discovered by Ludwig Krispenz of Red Hat.

Multiple memory leaks in the normalization functionality in 389 Directory Server before 1.2.7.5 allow remote attackers to cause a denial of service (memory consumption) via "badly behaved applications," related to (1) SlapiAttr mishandling in the DN normalization code and (2) pointer mishandling in the syntax normalization code, a different issue than CVE-2011-0019.

It was discovered that 389 / Red Hat Directory Server's setup scripts set insecure permissions (0777) on the /var/run/dirsrv directory used to store Directory Server's pid files when multiple Directory Server instances were configured on the system to be run under the different unprivileged users.

A local user could use this flaw to create, remove or replace pid files in this directory, possibly preventing correct start of the Directory Server instances, or causing Directory Server init script to kill arbitrary process during the Directory Server shutdown.

It was found that the 389 Directory Server did not properly restrict access to entries when the 'nsslapd-allow-anonymous-access' configuration setting is set to 'rootdse'. An anonymous user could connect to the LDAP database and, if the search scope is set to BASE, obtain access to information outside of the rootDSE. The 'rootdse' option exists to provide anonymous access to the rootDSE but no other entries in the directory. An administrator could believe that directory entries are being restricted with this option enabled, however the information provided would be the same as if 'nsslapd-allow-anonymous-access' were set to 'on'.

ACI's are still properly evaluated despite this flaw, so this can easily be mitigated by removing the anonymous read ACL.

The acllashandlegroupentry function in servers/plugins/acl/acllas.c in 389 Directory Server before 1.2.10 does not properly handled access control instructions (ACIs) that use certificate groups, which allows remote authenticated LDAP users with a certificate group to cause a denial of service (infinite loop and CPU consumption) by binding to the server.