Red Hat Directory Server 13.2 container image update

The fix for CVE-2024-2199 in 389-ds-base was insufficient to cover all scenarios. in certain product versions, an authenticated user may cause a server crash while modifying userPassword using malformed input.

A flaw was found In 389-ds-base. When the Content Synchronization plugin is enabled, an authenticated user can reach a NULL pointer dereference using a specially crafted query. This flaw allows an authenticated attacker to cause a denial of service. This CVE is assigned against an incomplete fix of CVE-2021-3514.

A flaw was found in RHDS 11 and RHDS 12. While browsing entries LDAP tries to decode the userPassword attribute instead of the userCertificate attribute which could lead into sensitive information leaked. An attacker with a local account where the cockpit-389-ds is running can list the processes and display the hashed passwords. The highest threat from this vulnerability is to data confidentiality.

Important: redhat-ds:11 security update

An access control bypass vulnerability found in 389-ds-base. That mishandling of the filter that would yield incorrect results, but as that has progressed, can be determined that it actually is an access control bypass. This may allow any remote unauthenticated user to issue a filter that allows searching for database items they do not have access to, including but not limited to potentially userPassword hashes and other sensitive data.

Summary: An unauthenticated user can cause a systematic server crash while sending a specific extended search request.

Description: 389-ds-base in RHEL 9.4 - RHDS 12.4, supports a new matching rule (inchain or 1.2.840.113556.1.4.1941). This matching rule requires that the matching attribute has a DN syntax. If the attribute in the ldap client request is not DN syntax, the server logs a message. The format of the message requires an attribute but as the attribute is missing, it triggers a SEGV.

Steps to reproduce: See below

The fix for CVE-2024-2199 in 389-ds-base was insufficient to cover all scenarios. in certain product versions, an authenticated user may cause a server crash while modifying userPassword using malformed input.

Multiple memory leaks in Red Hat Directory Server 7.1 before SP7, Red Hat Directory Server 8, and Fedora Directory Server 1.1.1 and earlier allow remote attackers to cause a denial of service (memory consumption) via vectors involving (1) the authentication / bind phase and (2) anonymous LDAP search requests.

A flaw was found in a Accept Language HTTP header parsers implemented in adminutil library used by various Red Hat Directory Server's Administration Server's CGI scripts. A remote attacker able to connect to Administration Server web interface could cause a CGI scripts to crash, or possibly execute an arbitrary code.

Issue affects: - Red Hat Directory Server 7.1 - adminutil packages shipped in Red Hat Directory Server 8 and Fedora Directory Server, prior to adminutil version 1.1.7

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

It was discovered that multiple CGI scripts used by Red Hat / Fedora Directory Server did not properly sanitize %-escaped inputs, resulting in a possibility to conduct cross-site scripting (XSS) attacks.

Issue was caused by a flow in an adminutil library that contain common functionality used by multiple CGI scripts, such as affected GET / POST argument parsing.

Issue is know to affect some Administration Express scripts and Directory Server Gateway (DSGW) scripts.

Affected version: Red Hat Directory Server 7.1 Red Hat Directory Server 8 (flaw limited to Administration Express issues, as DSGW component is not shipped) Fedora Directory Server

Buffer overflow in the regular expression handler in Red Hat Directory Server 8.0 and 7.1 before SP6 allows remote attackers to cause a denial of service (slapd crash) and possibly execute arbitrary code via a crafted LDAP query that triggers the overflow during translation to a regular expression.

Red Hat Directory Server 7.1 before SP4 uses insecure permissions for certain directories, which allows local users to modify JAR files and execute arbitrary code via unknown vectors.

Richard Megginson discovered a shell command injection flaw in the Admin Server's replication monitor CGI perl script repl-monitor-cgi.pl. Script parameters were not properly sanitized prior to being passed to system() function. An attacker able to access replication monitor CGI script could execute arbitrary shell command with privileges of Admin Server.

Affected versions: - Red Hat Directory Server 7.1 - Admin Server runs with root privileges - Red Hat Directory Server 8 - Admin Server runs under an unprivileged user, following users by default: - nobody on Red Hat Enterprise Linux and Solaris - daemon on HP-UX - Fedora Directory Server - Admin Server runs under an unprivileged user, nobody by default

Red Hat Administration Server, as used by Red Hat Directory Server 8.0 EL4 and EL5, does not properly restrict access to CGI scripts, which allows remote attackers to perform administrative actions.

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.

A vulnerability in Red Hat Directory Server and the 389 Directory Server was discovered. The code that parses the GER request (gerparsecontrol()) can dereference a NULL pointer. An unauthenticated user able to communicate with the Directory Server could use a crafted search query that would cause the Directory Server to crash.

This issue has been assigned the name CVE-2010-2222.

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 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.

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.

A flaw was found in the way that the Red Hat Directory Server handled simple paged result searches. If an unauthenticated user were able to send multiple simple paged search requests to Directory Server, it could cause the server to crash.

389 Directory Server 1.2.11.15 (aka Red Hat Directory Server before 8.2.11-14) allows remote authenticated users to cause a denial of service (crash) via multiple @ characters in a GER attribute list in a search request.

A flaw was found in how Red Hat Directory Server and the 389 Directory Server would handle access controls to certain attributes of an entry. A user with access to the Directory Server could use a series of searches to guess the values of other attributes that they should not be able to see. If a user had access (authenticated or anonymous, depending on whether or not the Directory Server allows anonymous access), they could use this to obtain information that should be restricted due to access controls.

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.

When binding against a DN during authentication, the reply from 389-ds-base will be different whether the DN exists or not. This can be used by an unauthenticated attacker to check the existence of an entry in the LDAP database.

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.

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.

A flaw was found in how Red Hat Directory Server and the 389 Directory Server would handle access controls to certain attributes of an entry. A user with access to the Directory Server could use a series of searches to guess the values of other attributes that they should not be able to see. If a user had access (authenticated or anonymous, depending on whether or not the Directory Server allows anonymous access), they could use this to obtain information that should be restricted due to access controls.

It was discovered that the slapi-nis Directory Server plug-in did not correctly perform memory reallocation when handling user account information. A request for information about a group with many members, or a request for a user that belongs to a large number of groups, would cause a Directory Server to enter an infinite loop and consume an excessive amount of CPU time.

Acknowledgements:

This issue was discovered by Sumit Bose of Red Hat.