Patrick Cheong Shu Yang discovered that courier-authdaemon, the authentication daemon of the Courier Mail Server, grants access to accounts that are already deactivated. Investigation and attached patch by David H
Patrick Cheong Shu Yang discovered that courier-authdaemon, the authentication daemon of the Courier Mail Server, grants access to accounts that are already deactivated. Investigation and attached patch by David Härdeman.
Created attachment 73221 [details, diff] patch
Ccing maintainers. Not sure which of courier, courier-imap or courier-authlib needs to be patched... For the moment just prepare your fixes (no commit to Portage), we have no information about disclosure dates.
Public, see Debian bug : ======================================= authlib/authpam.c doesn't call pam_acct_mgmt meaning that no check is performed if the user should actually be permitted access. This also means that the problem lies with courier-authdaemon rather than courier-imap(-ssl). For an explanation of pam_acct_mgmt, see: http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam_appl-3.html "This function is typically called after the user has been authenticated. It establishes whether the user's account is healthy. That is to say, whether the user's account is still active and whether the user is permitted to gain access to the system at this time." also the example app at: http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam_appl-8.html I've included a patch which fixes the problem by restoring the pam_acct_mgmt call. I've built courier-authdaemon with this patch applied and verified that it does indeed fix the problem and it seems to have no side effects. I hope that a fixed version can be included in sarge as soon as possible since this could potentially be a security issue (e.g. if the account has been disabled, access would still be granted). ====================================== Maintainers: please patch affected packages.
Committed directly to stable except on mips, with the following Changelog entry: 06 Dec 2005; Scott Taylor <staylor@gentoo.org> +files/CVE-2005-3532.patch, +courier-authlib-0.57-r2.ebuild, +courier-authlib-0.57.20051116.ebuild: patch for Bug 113074 This one is ready for GLSA decision. I tend to vote NO.
Voting no.
After upgrading from courier-authlib-0.57-r1 to courier-authlib-0.57-r2, authdaemond started to write tons of: Dec 7 14:15:08 server authdaemond: nss_ldap: reconnecting to LDAP server... Dec 7 14:15:08 server authdaemond: nss_ldap: reconnected to LDAP server after 1 attempt(s) in syslog. I reverted back to -r1 and the log went away. So there is indeed a side effect, at least Gentoo if not Debian.
By rolling back, was that to a saved package or did you recompile -r1 to get back to it? What use flags were each version built with? Those messages have been suggested to be caused by an ldap server not maintaining a persistent connection, or by the authdaemon needing restarted after an interrupted connection. So thats probably not it, but I'll ask anyway if you've tried restarting ldap then restarting the authdaemon. What auth modules are loaded, and in what order, in the authmodulelist line of /etc/courier/authlib/authdaemonrc? Are you even wanting to use ldap, and if so, do you want to use courier's own ldap or do you want pam to handle the ldap queries? Do you only have the specific auth modules you need in that list? Perhaps the new test is letting authentications fall through to an unwanted auth module now instead of being treated as a failure on the spot.
I recompiled -r1. My list of USE flags is: +berkdb +crypt -debug +gdbm +ldap +mysql +pam -postgres I tried both orders for restarting ldap and authdaemon (first ldap followed authdaemon, then later authdaemon followed by ldap after reading a post in the newsgroup talking about such an issue if the order was wrong). It didn't help. For authmodulelist, I tried different settings: - with only "authpam" which filled the log. - with only "authldap" which didn't work (I'm really setup to use ldap through pam) - my current default is "authldap authpam authuserdb authshadow authcustom authpipe" (ie default setting minus mysql because I had a bunch of error messages in the log because of it a couple years ago). I do want ldap, using pam if possible.
Any modules that you don't actually configure and need are best left out of that list, mysql and ldap need configured in their own rc files in the same path as the authdaemonrc. Best would be to build without their use flags so they don't even get built. Its no fun to have a service refuse to start because a client library for the database changed when its not really using that database in the first place. Along those lines, have you run revdep-rebuild recently to check for broken libs? The pam ebuild should be the only dependancy courier directly talks to for this, but is pam finding all its dynamic libraries properly? What use flags was pam built with? When you have only authpam in there, despite filling up the logs, does it still actually process the authentications? Have you tried the authtest/authenum from the command line to see if its getting the right account info? The authentication call its making now should not be anything other pam-enabled programs dont already check. I think the configs in /etc/pam.d are pretty standard, but I wonder if maybe there is something amiss in there. And with the complaints from nss_ldap, is there maybe something in /etc/nsswitch.ldap or /etc/nscd.conf that its choking on? Is the nscd daemon running?
I run revdep every now and then. Just ran it now to make sure: nothing needs rebuilding. pam works fine. courier-authlib works fine with only authpam. sys-libs/pam-0.78-r3 +berkdb -nis +pam_chroot -pam_console -pam_timestamp -pwdb (-selinux) /etc/pam.d/pop and imap are unmodified auth required pam_nologin.so auth include system-auth account include system-auth session include system-auth the other imap and pop files are symlinks to those two. I did change system-auth to manage ldap auth required pam_env.so auth sufficient pam_ldap.so auth sufficient pam_unix.so use_first_pass likeauth nullok shadow auth required pam_deny.so account sufficient pam_unix.so account sufficient pam_ldap.so account required pam_deny.so password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 password sufficient pam_unix.so nullok md5 shadow use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so session required pam_limits.so session required pam_unix.so session required pam_mkhomedir.so skel=/etc/skel/ umask=077 session optional pam_ldap.so Other services using pam work fine and without warning (cvs, login, samba, ...). SSH is the only also showing this warning but it's not too often so it's not an issue. In the logs, I also see a "Nov 30 14:26:47 server -bash: nss_ldap: reconnecting to LDAP server..." now and then (~once a week). Not sure what causes it. You meant /etc/nsswitch.conf, not .ldap right? passwd: files ldap shadow: files ldap group: files ldap hosts: files dns networks: files dns services: db files protocols: db files rpc: db files ethers: db files netmasks: files netgroup: files bootparams: files automount: files aliases: files I don't use nscd. The service is stopped. The config file is unmodified (or at least I don't remember changing it).
We're exceeding my ldap experience here. Nothing else is really jumping out at me. The full contents of this (tiny) patch have been applied to the upstream codebase as of courier-authlib-0.58 which is in portage now. The authpam.c file between the patched 0.57-r2 and the new 0.58 from upstream are identical. If this change is really breaking things, then if nothing else, you at least won't be alone. Perhaps something elsewhere in 0.58 would make it work on your system. Have you tried either of the ~x86 ebuilds of the authlib? Additionally, the init script was updated here to actually pass the debug flags from authdaemonrc, activating the DEBUG_LOGIN flag might give you a better idea of what is happening behind the scenes.
Closing again. Feel free to reopen if this is a regression by the applied patch, otherwise open a new bug.
