nss_ldap is a module offered by Padl Software that allows a system to use LDAP directories as the source of information for user attributes (via getpwent, etc) and related data. A local denial of service condition is possible when nss_ldap is in use with nscd (name service caching daemon), as is the case in RedHat Linux 7.0,6.2 and 6.1 with LDAP support. Nscd is a multithreaded daemon program that processes these lookups before they are sent to nss_ldap. If an attacker makes a large number of LDAP information requests, moreso than threads nscd can handle, then they and all further requests can be blocked until the system is reset or the nscd process is killed. This can be a very effective local denial of service attack. The reason for this condition is mutual dependence of two components on resources being free and blocking until this is the case. The problem occurs in a situation where nscd is very busy and all threads are in use (an attacker can of course create this...
nss_ldap is a module offered by Padl Software that allows a system to use LDAP directories as the source of information for user attributes (via getpwent, etc) and related data. A local denial of service condition is possible when nss_ldap is in use with nscd (name service caching daemon), as is the case in RedHat Linux 7.0,6.2 and 6.1 with LDAP support. Nscd is a multithreaded daemon program that processes these lookups before they are sent to nss_ldap. If an attacker makes a large number of LDAP information requests, moreso than threads nscd can handle, then they and all further requests can be blocked until the system is reset or the nscd process is killed. This can be a very effective local denial of service attack. The reason for this condition is mutual dependence of two components on resources being free and blocking until this is the case. The problem occurs in a situation where nscd is very busy and all threads are in use (an attacker can of course create this environment). When request number n is made (n being the maximum number of threads that nscd will handle), nss_ldap locks a mutex (protecting critical memory shared between threads from race conditions) before it attempts to contact the LDAP server. All other lookup requests are blocked (they hang) until this mutex is unlocked since this is normally a rather quick process. nss_ldap then calls gethostbyname() to resolve the address of the LDAP server. Unfortunately glibc passes the gethostbyname() request to nscd, where it is blocked until a thread has been freed. This will never happen however, since the pending threads are all blocked until the nss_ldap request that called gethostbyname() releases the mutex. All system functions that depend on host lookups or user information retrieval will be unusable until a system reboot or the nscd process is killed (root must already be logged in, login will not work nor will any remote access utility).
