Bug 367461 (CVE-2007-5794)

Summary: CVE-2007-5794 nss_ldap randomly replying with wrong user's data
Product: [Other] Security Response Reporter: Josh Bressers <bressers>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: bressers, jakub, jburley, joshkel, k.georgiou, mattdm, me, mitr, mjc, ngaywood, oliver, tmraz, wtogami
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-12-22 23:13:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 155187, 252337    
Bug Blocks:    
Description Flags
Patch from above URL for posterity
Patch from above URL for posterity none

Description Josh Bressers 2007-11-05 20:58:22 UTC
+++ This bug was initially created as a clone of Bug #154314 +++

Description of problem:
Second time already when I hear nss_ldap is replying with wrong results and
causing peoples' mails to be shown to wrong people:


Something should really be done about this. At the very least I'm adding a check
to make sure getpwnam() returns the same user name that is being requested, and
if not put out some huge warnings about something being broken..

-- Additional comment from tjanouse on 2007-02-06 11:08 EST --
Oh yeah, got it.

The problem relies in the fact that if an application is linked against
pthread and uses a nss_ldap call and then forks, both processes share the ldap
connection, having no locking mechanism, and bad things happen. This is the
case with dovecot -- dovecot-auth is linked with pthread and uses pam in
forked processes. A race condition causes dovecot-auth to receive a reply that
should have gone to pam.

The direct cause of this is that an assumption that __pthread_once is nonnull
(ldap-nss.c:1048) implies __pthread_atfork being nonnull (ldap-nss.c:504,
bits/libc-lock.h:290) is plain wrong. These two variables have no connection
to each other and each of them becomes non-null at the time linker resolves
them, which happens upon them being called. And it happens upon them being
called in the object that checks for them -- that means calling pthread_atfork
in dovecot has no effect on __pthread_atfork value in nss_ldap and vice versa.

For some not so obvious reason __pthread_once is nonnull at the enter of main
function, __pthread_atfork is null. This means that nss_ldap assumes we have
pthreads working, calls the __libc_atfork (ldap-nss.c:504), which is a noop in
this case, and then has no idea about the forks and such.

The easiest solution would be to help nss_ldap's configure find pthreads
(telling it to -lpthread), which would make nss_ldap use pthreads directly and
avoid such crazy things -- and using those libc internal functions is bad
anyway, but I'm not sure whether we should do it.

Also, we could fix it to chech for both __pthread_once and __pthread_atfork 
but it would not find them and use the pid-comparing method, which is probably 

I hope this information helps :)

-- Additional comment from tjanouse on 2007-05-10 09:16 EST --
The upstream has accepted my two patches:

Comment 1 Josh Bressers 2007-11-05 21:00:37 UTC
Created attachment 248591 [details]
Patch from above URL for posterity

Comment 2 Josh Bressers 2007-11-05 21:00:55 UTC
Created attachment 248601 [details]
Patch from above URL for posterity

Comment 3 Vincent Danen 2010-12-22 23:13:53 UTC
This was addressed via:

Red Hat Enterprise Linux version 5 (RHSA-2008:0389)
Red Hat Enterprise Linux version 4 (RHSA-2008:0715)