REDHAT-BUG-2509696: High severity 389 Directory Server 389 Directory Server vulnerability
A flaw was found in 389 Directory Server. The opsharedsearch function in opshared.c does not check for a NULL backend pointer when reusing a paged-results slot in the bename (USEONEBACKEND control) code path. An unauthenticated client can exploit this by sending two SEARCH requests on the same connection: the first names a non-existent backend via the USEONEBACKEND control with a Simple Paged Results (SPR) empty cookie, storing NULL as the backend in a paged-results slot; the second names a valid backend with an SPR cookie referencing that slot, causing the server to retrieve the stored NULL and call slapibeRlock(NULL), which dereferences the NULL pointer and crashes the ns-slapd process. This is reachable pre-authentication because control and paged-results processing runs before search authorization. Paged results and anonymous access are both enabled by default.
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
Any unauthenticated client that can connect to the directory server can trigger it. Authentication is not required because the affected control and paged-results handling occurs before search authorization.
Are default deployments affected?
Yes. Both anonymous access and paged results are enabled by default, making the vulnerable path reachable without configuration changes.
What request sequence is required to trigger the crash?
An attacker sends two SEARCH requests over the same connection. The first uses USE_ONE_BACKEND with a non-existent backend and an empty Simple Paged Results cookie; the second specifies a valid backend and reuses the paged-results slot through its cookie.
What is the impact of successful exploitation?
The ns-slapd process crashes when it attempts to lock a NULL backend pointer. This is a denial-of-service condition.