net-mail/cmd5checkpw is installed setuid cmd5checkpw, but it does not drop privileges before calling execvp(), i.e. the invoked program retains the
cmd5checkpw euid. Local users that know at least one valid
/etc/poppasswd user/password combination can read the /etc/poppasswd file.
Steps to Reproduce:
1. emerge net-mail/cmd5checkwp
2. create /etc/poppasswd to contain:
uid=1001(fw) gid=100(users) groups=5(tty),10(wheel),16(cron),100(users)
$ perl -e 'print("user\0pass\0\pass\0");' > test
$ /bin/cmd5checkpw id
uid=1001(fw) gid=100(users) euid=1000(cmd5checkpw)
user obtains euid=1000(cmd5checkpw).
Drop euid before execvp().
If cmd5checkpw really needs to be setuid, it should set its effective uid to
that the real uid of the calling process. I'll add a patch to do this, but
i'd prefer cmd5checkpw to not be setuid (this might break things though)
Created attachment 48674 [details, diff]
cmd5checkpw: set euid to uid of calling user
net-mail herd, please comment (on the need to be SUID and on the patch)
Florian: did you try to contact upstream yet ?
I emailed firstname.lastname@example.org about this a few minutes ago. (same Bugreport + patch)
(I thought this was a Gentoo specific bug at first before seeing that upstream
docs suggest making cmd5checkpw setuid)
Reassigning this as a vulnerability, since it's a clear local information leak.
Florian: any answer from upstream ?
No reply from upstream until now.
The last 'news' item on the project homepage is dated 09.10.2000...
net-mail: please comment.
Can cmd5checkwp not be setuid ? If not, what do you think of the patch ?
langthang asked me to comment on this bug. There we go.
Quoting the manpage of cmd5checkpw:
/etc/poppasswd - this file contains pairs of logins and clear text
passwords separated by ":". It looks like this:
Best way to protect it is to make it readable only for one specific
user different than you normal system users and make cmd5checkpw suid
Therefore, I would say that cmd5checkpw has to be setuid if /etc/poppasswd is only readable by a specific user. But I also think that dropping the effective uid wouldn't hurt. If nobody else (robbat2?) sees a problem in here, we should apply the patch.
Robin, what do you think about this patch? Can we apply it?
Upstream looks dead...
net-mail: please apply the patch or drop the package.
The patch is now applied to cmd5checkpw-0.22-r2. The ebuild is currently in ~ARCH for testing. Please test it and comment on this bug again. Then we'll make a stabilization request to all affected architectures.
Thx Micheal, reopening for stable marking.
Arches please test and mark cmd5checkpw-0.22-r2 stable.
Stable on ppc and hppa.
Stable on alpha.
how is this being tested?(noone on amd64 apparently uses it)
Mike: I am not a cmd5checkpw user but it looks like a password changing system that will access a /etc/poppasswd (owned by the cmd5checkpw user and -rw-------).
Try creating a /etc/poppasswd file with pairs of logins and clear text passwords like this :
And validate you can change the password as a regular user. You can also vamidate that the exploit in bug description is no longer working.
Stable on mips.
stable on amd64
security, pls vote on GLSA need
I vote no glsa, please feel free to disagree ;)
Local users can get plaintext POP passwords for their coworkers... I vote yes.
not absolutely necessary, but a GLSA on this might be a good idea
voting for one
arm should park stable to benefit from GLSA