Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 75820 - net-mail/poppassd_pam: ANY old password is accepted for password changing
Summary: net-mail/poppassd_pam: ANY old password is accepted for password changing
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: x86 Linux
: Highest critical (vote)
Assignee: Gentoo Security
Whiteboard: B0 [glsa] koon / 20050111
Depends on:
Reported: 2004-12-27 10:12 UTC by Martin bene
Modified: 2005-01-11 11:58 UTC (History)
16 users (show)

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


Note You need to log in before you can comment on or make changes to this bug.
Description Martin bene 2004-12-27 10:12:44 UTC
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!

auth       required service=system-auth
account    required service=system-auth
session    required service=system-auth
Comment 1 Luke Macken (RETIRED) gentoo-dev 2005-01-10 05:55:09 UTC
net-mail, please confirm/advise.
Comment 2 Thierry Carrez (RETIRED) gentoo-dev 2005-01-10 06:12:06 UTC
Replacing herd by individual members (yes, Bugzilla sucks).
Comment 3 Thierry Carrez (RETIRED) gentoo-dev 2005-01-10 06:18:00 UTC
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...
Comment 4 Thierry Carrez (RETIRED) gentoo-dev 2005-01-10 07:39:47 UTC
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.
Comment 5 Thierry Carrez (RETIRED) gentoo-dev 2005-01-10 08:16:58 UTC
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 ?
Comment 6 Thierry Carrez (RETIRED) gentoo-dev 2005-01-10 08:43:11 UTC
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 */

We should replace this buggy package by the poppassd-ceti version... please see bug 37434 for an ebuild.
Comment 7 Martin bene 2005-01-10 08:54:37 UTC
Yep, that's what I ended up doing. poppasswd-ceti (and the ebuild from bug 37434) work OK for me.
Comment 8 Tuan Van (RETIRED) gentoo-dev 2005-01-10 21:42:41 UTC
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. 
Comment 9 Marcus D. Hanwell (RETIRED) gentoo-dev 2005-01-10 22:42:11 UTC
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?
Comment 10 Thierry Carrez (RETIRED) gentoo-dev 2005-01-11 00:51:32 UTC
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 ?
Comment 11 Thierry Carrez (RETIRED) gentoo-dev 2005-01-11 00:56:11 UTC
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.
Comment 12 Marcus D. Hanwell (RETIRED) gentoo-dev 2005-01-11 04:38:00 UTC
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.
Comment 13 Thierry Carrez (RETIRED) gentoo-dev 2005-01-11 04:49:43 UTC
Yes it does.

Coordinated disclosure scheduled for tomorrow 20050112, to give some time for others to prepare fixes and advisories.
Comment 14 Thierry Carrez (RETIRED) gentoo-dev 2005-01-11 06:20:00 UTC
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 ?
Comment 15 Thierry Carrez (RETIRED) gentoo-dev 2005-01-11 07:12:03 UTC
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.
Comment 16 Martin bene 2005-01-11 07:21:49 UTC
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,

Comment 17 Thierry Carrez (RETIRED) gentoo-dev 2005-01-11 08:25:25 UTC
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)
Comment 18 Marcus D. Hanwell (RETIRED) gentoo-dev 2005-01-11 09:31:59 UTC
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.
Comment 19 Thierry Carrez (RETIRED) gentoo-dev 2005-01-11 11:58:39 UTC
GLSA 200501-22