Bug 367461 - (CVE-2007-5794) CVE-2007-5794 nss_ldap randomly replying with wrong user's data
CVE-2007-5794 nss_ldap randomly replying with wrong user's data
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,source=redhat,reported=200...
: Security
Depends On: 155187 252337
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-05 15:58 EST by Josh Bressers
Modified: 2010-12-22 18:13 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-22 18:13:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch from above URL for posterity (2.09 KB, patch)
2007-11-05 16:00 EST, Josh Bressers
no flags Details | Diff
Patch from above URL for posterity (1.12 KB, patch)
2007-11-05 16:00 EST, Josh Bressers
no flags Details | Diff

  None (edit)
Description Josh Bressers 2007-11-05 15:58:22 EST
+++ 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:

http://www.dovecot.org/list/dovecot/2005-March/006345.html
http://www.dovecot.org/list/dovecot/2005-April/006859.html

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@redhat.com 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 
slower.

I hope this information helps :)


-- Additional comment from tjanouse@redhat.com on 2007-05-10 09:16 EST --
The upstream has accepted my two patches:
 http://people.redhat.com/tjanouse/dovecot/154314/sent_upstream/
Comment 1 Josh Bressers 2007-11-05 16:00:37 EST
Created attachment 248591 [details]
Patch from above URL for posterity
Comment 2 Josh Bressers 2007-11-05 16:00:55 EST
Created attachment 248601 [details]
Patch from above URL for posterity
Comment 3 Vincent Danen 2010-12-22 18:13:53 EST
This was addressed via:

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

Note You need to log in before you can comment on or make changes to this bug.