Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 198390 - sys-auth/nss_ldap < 258 race condition (CVE-2007-5794)
Summary: sys-auth/nss_ldap < 258 race condition (CVE-2007-5794)
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
URL: http://secunia.com/advisories/27670/
Whiteboard: B4? [glsa]
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-07 19:29 UTC by Sune Kloppenborg Jeppesen
Modified: 2020-04-03 22:49 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sune Kloppenborg Jeppesen gentoo-dev 2007-11-07 19:29:49 UTC
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 :)
Comment 1 Sune Kloppenborg Jeppesen gentoo-dev 2007-11-07 19:30:09 UTC
ldap-bugs please advise.
Comment 2 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2007-11-08 03:08:35 UTC
Both patches on the RH Bugzie URL are already present upstream as of nss_ldap-256, so all we need to do is stabilize nss_ldap-257.2 (which has been in the tree 29 days already).

I'm aware of bug 198408 that was a build weirdness, and bug 165638 for the kerberos folk - but neither of these should hold back 257.2 going to stable.

Also, this raises bug 197467 to being security critical, you'll have to chase amd64 there to bump that package and stabilize/issue GLSA.
Comment 3 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2007-11-08 03:20:14 UTC
minor update, I just put nss_ldap-258 into the tree, it contained a singular upstream change (5 lines only) fixing nss_srv_domain usage, and I put the kerberos fix in at the same time, and hopefully resolved the build bug 198408. It may be a better candidate than 257.2 for that reason.
Comment 4 Robert Buchholz (RETIRED) gentoo-dev 2007-11-08 03:28:40 UTC
(In reply to comment #3)
> and hopefully resolved the build bug 198408.
> It may be a better candidate than 257.2 for that reason.

Let's wait for a reply for today.


> Also, this raises bug 197467 to being security critical, you'll have to chase
> amd64 there to bump that package and stabilize/issue GLSA.

I added it to our emul-baselibs bug 196865.
Comment 5 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2007-11-08 11:01:03 UTC
rbu/security: bug 198408 resolved and 258 works for that user now, you can go for stabilizing 258.
Comment 6 Sune Kloppenborg Jeppesen gentoo-dev 2007-11-08 11:25:20 UTC
Thx Robbat.

Arches please test and mark stable. Target keywords are:

nss_ldap-258.ebuild:KEYWORDS="alpha amd64 hppa mips ppc ppc64 sparc x86"
Comment 7 Jeroen Roovers gentoo-dev 2007-11-08 16:05:00 UTC
Stable for HPPA.
Comment 8 Markus Rothe (RETIRED) gentoo-dev 2007-11-08 19:52:12 UTC
ppc64 stable
Comment 9 Dawid Węgliński (RETIRED) gentoo-dev 2007-11-08 20:32:44 UTC
x86 stable
Comment 10 Raúl Porcel (RETIRED) gentoo-dev 2007-11-08 21:19:15 UTC
alpha/sparc stable
Comment 11 Tobias Scherbaum (RETIRED) gentoo-dev 2007-11-13 19:56:11 UTC
ppc stable
Comment 12 Steve Dibb (RETIRED) gentoo-dev 2007-11-14 03:56:10 UTC
amd64 stable
Comment 13 Robert Buchholz (RETIRED) gentoo-dev 2007-11-14 17:49:17 UTC
Voting YES because of the high impact of dovecot returning wrong inboxes.
Comment 14 Pierre-Yves Rofes (RETIRED) gentoo-dev 2007-11-18 15:50:21 UTC
yes too, request filed.
Comment 15 Pierre-Yves Rofes (RETIRED) gentoo-dev 2007-11-25 21:58:49 UTC
GLSA 200711-33