It was found that 389 Directory Server is vulnerable to a remote password disclosure via timing attack. Due to the use of strcmp and memcmp in the verification of passwords and hashes, remote attacker is able to tell the difference between computation times which makes him able to retrieve the password after many tries.

This affects systems storing passwords in plain text. Systems using unsalted hashes might be unsafe as well if using weak hash algorithms, however the attack would be very time-consuming.

Ludwig Krispenz from Red Hat reported that there is a configuration switch to prevent writing unhashed passwords into the changelogs. Unfortunately if the switch is turned on the attribute unhashed#user#password is not written to the changelog, but the hashing of the attribute value itself is also bypassed.

Versions affected are 389 versions 1.3.1 and later, this means RHEL7.0 and later and Fedora20 and later.

The severity seems to be limited, since: - the option is not widely known and advertised and only available in a recent version - the access to the userpassword attribute is usually protected by acis not to be readable

Statement:

This issue did not affect the versions of 389-ds-base as shipped with Red Hat Enterprise Linux 6.

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.

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.

389 Directory Server before 1.2.7.1 (aka Red Hat Directory Server 8.2) and HP-UX Directory Server before B.08.10.03, when audit logging is enabled, logs the Directory Manager password (nsslapd-rootpw) in cleartext when changing cn=config:nsslapd-rootpw, which might allow local users to obtain sensitive information by reading the log.

setup-ds.pl and setup-ds-admin.pl scripts used to configure Red Hat / 389 Directory Server instances and administration server instances creates a cache file containing configuration parameters provided by administrator configuring directory server. The file is created in /tmp with random name as setupXXXXXX.inf. It contains information such as directory server instance name, user and group under with ns-slapd should run, network port directory and administration server should listen on, base DN and administrative user names and accounts. This file is created with permissions depending on current umask setting, which is 022 for root account by default, which results in file being created as world readable. Any local user can take advantage of the weak file permissions and obtain administrative account passwords, which give them full control over directory server instance.

This file is removed at the end of the setup run which limits exposure, but it is not removed when setup is started with -k or --keepcache.

For additional details and patch changing setup scripts to always create cache file with restricted permissions, see: https://bugzilla.redhat.com/showbug.cgi?id=593392

It was discovered that Red Hat Directory Server and Fedora Directory Server is prone to a temporary denial of service attack (high CPU usage) via crafted LDAP search patterns. LDAP search patterns are internally translated to regular expressions. If the regular expression is matched against specially crafted record already stored in the LDAP, it may cause regular expression NFA to iterate over large amount of states, causing one slapd thread to occupy CPU for excessive amount of time.

Additionally, due to a current design of the regular expression handling code, only one slapd thread can execute regular expression NFA code at the time. Because of that, during the processing of such CPU intensive search request, all other search requests using patterns are blocked.

Affected version: Red Hat Directory Server 7.1 and 8 Fedora Directory Server 1.1.1