CVE-2024-3657: 389-ds-base LDAP DoS Vulnerability

CVE-2024-3657 Overview

CVE-2024-3657 is a denial-of-service vulnerability in the 389 Directory Server (389-ds-base), an enterprise Lightweight Directory Access Protocol (LDAP) server maintained by Red Hat. A specially-crafted LDAP query can trigger a failure condition in the directory server process, causing the service to become unavailable to legitimate clients. The flaw is classified under [CWE-20: Improper Input Validation] and affects directory server deployments commonly used for identity management, authentication, and centralized account services across Linux environments. Because LDAP servers underpin authentication infrastructure, an outage can cascade to dependent applications and users.

Critical Impact
An unauthenticated remote attacker can send a malformed LDAP query that causes the 389 Directory Server to fail, resulting in a denial of service for all authentication and directory lookup operations.

Affected Products

Red Hat Directory Server (389-ds-base)
Red Hat Enterprise Linux Identity Management (IdM) deployments using 389-ds-base
Debian distributions packaging 389-ds-base (see Debian LTS advisory)

Discovery Timeline

2024-05-28 - CVE-2024-3657 published to the National Vulnerability Database
2024-06 through 2024-10 - Red Hat releases successive security advisories (RHSA-2024:3591, 3837, 4092, 4209, 4210, 4235, 4633, 5690, 6576, 7458)
2025-01 - Debian LTS publishes fixed packages
2025-02 - Red Hat releases additional advisory RHSA-2025:1632
2026-04-15 - Last updated in the NVD database

Technical Details for CVE-2024-3657

Vulnerability Analysis

The vulnerability resides in how 389-ds-base parses and processes incoming LDAP queries. A crafted query payload causes the directory server process to encounter an unhandled failure state, terminating availability of the service. Because LDAP listens on TCP ports 389 (cleartext) and 636 (LDAPS) and accepts queries before bind authentication occurs for several operation types, the failure can be triggered without valid credentials. The denial-of-service condition affects the entire directory instance, not just a single connection or client session. Recovery requires the directory server process to be restarted by an administrator or a service supervisor.

Root Cause

The root cause is improper input validation [CWE-20] on LDAP request fields. The server does not sufficiently sanity-check structural elements of the request before passing them to internal processing routines, leading to a fatal condition when a malformed value is encountered.

Attack Vector

The vulnerability is exploitable over the network with low attack complexity and no required privileges or user interaction. An attacker with TCP reachability to the LDAP listener can submit the malformed query directly. The impact is limited to availability — confidentiality and integrity of directory data are not affected.

No verified public proof-of-concept code is available. See the Red Hat CVE Report CVE-2024-3657 and Red Hat Bug Report #2274401 for vendor-supplied technical details.

Detection Methods for CVE-2024-3657

Indicators of Compromise

Unexpected restarts or crashes of the ns-slapd process recorded in system journal or systemd logs
Abrupt termination entries or fatal error messages in /var/log/dirsrv/slapd-<instance>/errors
Spikes in failed LDAP connections, client reconnect storms, or authentication failures from downstream applications
Inbound LDAP traffic from unexpected sources targeting TCP/389 or TCP/636 immediately preceding a service failure

Detection Strategies

Monitor the health and uptime of the ns-slapd process and alert on unplanned termination events
Inspect directory server access and error logs for malformed request patterns and parser errors preceding a crash
Correlate LDAP service downtime with network flow records to identify the originating client of the triggering query
Apply network intrusion detection signatures that flag anomalous LDAP request structures targeting 389-ds-base listeners

Monitoring Recommendations

Forward dirsrv error and access logs to a centralized logging platform for retention and correlation
Track LDAP query rate, connection counts, and process restart counts as service-level indicators
Set alerts for repeated ns-slapd restarts within short time windows, which can indicate active exploitation attempts
Restrict and log access to LDAP ports from unauthorized network segments

How to Mitigate CVE-2024-3657

Immediate Actions Required

Apply the vendor patches referenced in the relevant Red Hat Security Advisories (RHSA-2024:3591 through RHSA-2025:1632) for your 389-ds-base version
Debian and derivative users should update to the fixed 389-ds-base package per the Debian LTS Announcement January 2025
Restrict network access to LDAP listeners (TCP/389, TCP/636) to trusted client subnets using host or perimeter firewalls
Verify directory server logging and process supervision are configured to capture and recover from unexpected terminations

Patch Information

Red Hat has issued multiple errata addressing CVE-2024-3657 across supported Red Hat Enterprise Linux and Red Hat Directory Server streams. Refer to RHSA-2024:3591, RHSA-2024:4092, RHSA-2024:4633, RHSA-2024:7458, and RHSA-2025:1632 for stream-specific fixed package versions. The Debian project shipped corrected 389-ds-base packages in January 2025.

Workarounds

Limit LDAP exposure to known clients using firewall rules until patches are applied
Require client TLS authentication on the LDAPS listener where feasible to reduce the population of hosts that can submit queries
Ensure ns-slapd runs under systemd with Restart=on-failure so that the service is automatically restored after a crash
Deploy rate limiting and connection caps at the network layer to slow repeated exploitation attempts

bash

# Example: restrict LDAP access to a trusted subnet with firewalld
sudo firewall-cmd --permanent --zone=public --remove-service=ldap
sudo firewall-cmd --permanent --zone=public --remove-service=ldaps
sudo firewall-cmd --permanent --new-zone=ldap-trusted
sudo firewall-cmd --permanent --zone=ldap-trusted --add-source=10.0.0.0/24
sudo firewall-cmd --permanent --zone=ldap-trusted --add-service=ldap
sudo firewall-cmd --permanent --zone=ldap-trusted --add-service=ldaps
sudo firewall-cmd --reload

# Ensure ns-slapd is auto-restarted on failure
sudo systemctl edit dirsrv@<instance>.service
# Add:
# [Service]
# Restart=on-failure
# RestartSec=5s
sudo systemctl daemon-reload