Red Hat Directory Server 13.2 container image update

Important: redhat-ds:11 security 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.

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.

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

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.

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.

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.

A vulnerability was discovered in the 389 Directory Server that allows an unauthenticated attacker with network access to the LDAP port to cause a denial of service. The denial of service is triggered by a single message sent over a TCP connection, no bind or other authentication is required. The message triggers a segmentation fault that results in slapd crashing.

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.

A flaw was found in 389-ds-base. The server can be crashed by an anonymous client through a ldapmodify command with a large DN argument potentially causing denial of service.

References:

https://bugzilla.redhat.com/showbug.cgi?id=1614820

A flaw was found in 389-ds-base that was introduced after CVE-2016-5405 fix. A lack of size check in slapictmemcmp() function may lead to authentication bypass through pre-hashed userPassword attributes under highly specific circumstances.

The directory server password lockout policy prevents binds from operating once a threshold of failed passwords has been met. If attacker during this lockout binds with the correct password, a different error code is returned. This means that attacker has no ratelimit or penalty during the account lock, and can continue to attempt passwords via bruteforce.

Upstream bug:

https://pagure.io/389-ds-base/issue/49336

Upstream patch:

https://pagure.io/389-ds-base/c/33db32a3e14b849d

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.

It was found that 389 Directory Server is vulnerable to a flaw in which the default ACI (Access control instructions) could be read by an anonymous user. This could lead to leakage of sensitive information.

Reference: https://fedorahosted.org/389/ticket/48852

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.

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.

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.

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.

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.

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

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.

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