This is a duplicate of 37434; The severity / importance of the old entry do not match actual impact, so I'm adding a new bug. Since poppasswd_pam accepts anything whatsoever as the old password and proceeds to change to set the new password, this is pretty much an instant remote root compromise for any system where poppasswd_pam is installed. Please tell me I somehow horribly missconfigured it and this can't happen with a sane configuration! /etc/pam.d/poppasswd: auth required pam_stack.so service=system-auth account required pam_stack.so service=system-auth session required pam_stack.so service=system-auth
net-mail, please confirm/advise.
Replacing herd by individual members (yes, Bugzilla sucks).
Note that it's a remote root compromise only if you accept the root password somewhere to execute code with root privs (a SSHD with AllowRootLogin for example). Anyway, I'll try to verify this quickly. Next time, please post your bug under "Gentoo Security" product so that it gets affected to the security team automatically...
I can reproduce the problem. poppassd_pam is broken. If you use it with Gentoo-supplied default configuration it won't work. If you try to use it with others configuration it may allow you to change the password without authenticating in the first place. Their error is that they call pam_chauthtok as root and expect it will do an authentication check. Guess what... it doesn't. I am trying to figure out a quick patch but this is really a mess. I think we should mask it.
One way of having it working is to change "user = root" in xinetd.d/poppassd to "user = nobody" and then chmod u+s a+x /usr/bin/poppassd. This will force PAM to to use called-as-user behaviour and will force authentication before chauthtok. That said, I can't recommend running this SUID root and I won't fix it... PAM is hell to debug. Think of it as the behaviour of the passwd command. Called with uid 0 it won't ask you for the old password. The proper fix is to do a pam_authenticate before the pam_chauthtok. net-mail, any input ?
Debian uses poppassd-ceti. It does the right thing : if(pam_authenticate(pamh, 0) != PAM_SUCCESS) { WriteToClient ("500 Old password is incorrect."); syslog(LOG_ERR, "old password is incorrect for user %s", user); /* pause to make brute force attacks harder */ sleep(BAD_PASS_DELAY); exit(1); } We should replace this buggy package by the poppassd-ceti version... please see bug 37434 for an ebuild.
Yep, that's what I ended up doing. poppasswd-ceti (and the ebuild from bug 37434) work OK for me.
Marcus will commit and maintain poppasswd-ceti. CCing him so he can access to the bug. I am all for package.mask/remove poppasswd_pam.
I have committed the new ebuild, with KEYWORDS ~amd64 and ~x86. Please let me know if there are any problems with it at all. Are security package.masking/removing poppassd_pam?
cryos: would do it if we could :) I think it should be removed and replaced by poppassd-ceti as a "move" in /usr/portage/profiles/updates so that users get an easy upgrade path... Could you do it ?
We'll need x86 stable on this... cryos, if you use x86 and feel comfortable that it works better than the old one (and it could not work worse, believe me) then please mark it stable on x86. Martin, if you're on x86, please also test that the new ebuild is OK.
I have been using poppassd_ceti for about one year without any issues. Just tested again on x86 and amd64 - no problems installing from the modified ebuild. I have marked it stable on x86. I have also added an entry to profiles/updates/1Q-2005 as you suggested and removed poppassd_pam. I think that takes care of everything with this bug, please let me know if not.
Yes it does. Coordinated disclosure scheduled for tomorrow 20050112, to give some time for others to prepare fixes and advisories.
Apparently the updates file does not like it when a new move is added at the top rather than at the bottom... It doesn't update the cache with the current one. Putting the poppassd move at the bottom of the file apparently fixes it. Anyone with commit rights could fix that file ?
cryos: please ignore this. The fix of the 1Q-2005 file is NOT needed for the update to work. This will be disclosed in a few hours. Thanks everyone. Martin: You're credited in the GLSA as the discoverer of the problem. If you don't want your name to appear there, please tell me in the next 4 hours... after it will be too late.
While I did run into the problem independantly, it was discoverd and described previously by Marcus D. Hanwell on 2004-11-18 18:19 PST; (see comment #4 on Bug 37434). he also provided the poppassd_ceti ebuild. I think attribution to Marcus would be more apropriate. Thanks for fixing, Martin
We'll credit Marcus then. Marcus, if you don't want your name to appear on the GLSA please comment here before release date, which is 1900 UTC (yes, I know... it's soon, but upstream published the vulnerability so we're kinda in a hurry now)
Thanks Martin. Koon I hope the updates file didn't cause problems - didn't realise moves were usually added to the bottom of that file. I will remember in future.
GLSA 200501-22
