CVE-2012-1164

What it actually does

The flaw triggers an assertion failure inside slapd when an LDAP search request arrives with attrsOnly set to true, causing empty attribute lists to be generated and the daemon to terminate.

Why it matters to the business

Causes abrupt loss of directory service availability; with 98 downstream dependents the outage can cascade into authentication, identity, and application failures across multiple systems.

How an attack unfolds

An unauthenticated remote attacker sends a single crafted LDAP search query that sets the attrsOnly flag to true; the server processes the request, hits the internal assertion, and exits, producing a denial of service.

How to fix it

Upgrade OpenLDAP to 2.4.30 or newer; for tensorflow (Bitnami) deployments apply the fixed release 2.1.4.

How to confirm the fix worked

Confirm slapd version is 2.4.30 or later; replay a search query with attrsOnly=true in a test environment and verify the daemon remains running.

Typical attack path

1. Locate an exposed LDAP server (port 389/636)
2. Craft an LDAP search request with attrsOnly=true
3. Transmit the request to the server
4. Server hits assertion and terminates

How to detect it

Inspect slapd logs for assertion-failure messages or sudden daemon exits correlated with LDAP search activity; review system crash reports and service restart events.

• assertion failure
• slapd.*daemon exit
• attrsOnly.*true

What your security team should do

• Apply the fixed version immediately given the long public exposure window
• Restrict inbound LDAP traffic to trusted sources only
• Enable process monitoring and automatic restart with crash logging