198390 2007-11-07 19:29 0000 sys-auth/nss_ldap < 258 race condition (CVE-2007-5794) 2007-11-25 21:58:49 0000 1 1 1 Unclassified Gentoo Security Vulnerabilities unspecified All Linux RESOLVED FIXED http://secunia.com/advisories/27670/ B4? [glsa] P2 normal --- 1 jaervosz@gentoo.org security@gentoo.org ldap-bugs@gentoo.org mips@gentoo.org jaervosz@gentoo.org 2007-11-07 19:29:49 0000 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 :) jaervosz@gentoo.org 2007-11-07 19:30:09 0000 ldap-bugs please advise. robbat2@gentoo.org 2007-11-08 03:08:35 0000 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. robbat2@gentoo.org 2007-11-08 03:20:14 0000 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. rbu@gentoo.org 2007-11-08 03:28:40 0000 (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. robbat2@gentoo.org 2007-11-08 11:01:03 0000 rbu/security: bug 198408 resolved and 258 works for that user now, you can go for stabilizing 258. jaervosz@gentoo.org 2007-11-08 11:25:20 0000 Thx Robbat. Arches please test and mark stable. Target keywords are: nss_ldap-258.ebuild:KEYWORDS="alpha amd64 hppa mips ppc ppc64 sparc x86" jer@gentoo.org 2007-11-08 16:05:00 0000 Stable for HPPA. corsair@gentoo.org 2007-11-08 19:52:12 0000 ppc64 stable cla@gentoo.org 2007-11-08 20:32:44 0000 x86 stable armin76@gentoo.org 2007-11-08 21:19:15 0000 alpha/sparc stable dertobi123@gentoo.org 2007-11-13 19:56:11 0000 ppc stable beandog@gentoo.org 2007-11-14 03:56:10 0000 amd64 stable rbu@gentoo.org 2007-11-14 17:49:17 0000 Voting YES because of the high impact of dovecot returning wrong inboxes. py@gentoo.org 2007-11-18 15:50:21 0000 yes too, request filed. py@gentoo.org 2007-11-25 21:58:49 0000 GLSA 200711-33