|Summary:||sys-auth/nss_ldap < 258 race condition (CVE-2007-5794)|
|Product:||Gentoo Security||Reporter:||Sune Kloppenborg Jeppesen (RETIRED) <jaervosz>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Package list:||Runtime testing required:||---|
Description Sune Kloppenborg Jeppesen (RETIRED) 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 (RETIRED) 2007-11-07 19:30:09 UTC
ldap-bugs please advise.
Comment 2 Robin Johnson 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 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) 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 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 (RETIRED) 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 (RETIRED) 2007-11-08 16:05:00 UTC
Stable for HPPA.
Comment 8 Markus Rothe (RETIRED) 2007-11-08 19:52:12 UTC
Comment 9 Dawid Węgliński (RETIRED) 2007-11-08 20:32:44 UTC
Comment 10 Raúl Porcel (RETIRED) 2007-11-08 21:19:15 UTC
Comment 11 Tobias Scherbaum (RETIRED) 2007-11-13 19:56:11 UTC
Comment 12 Steve Dibb (RETIRED) 2007-11-14 03:56:10 UTC
Comment 13 Robert Buchholz (RETIRED) 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) 2007-11-18 15:50:21 UTC
yes too, request filed.
Comment 15 Pierre-Yves Rofes (RETIRED) 2007-11-25 21:58:49 UTC