of some code, I came across a funny vulnerability inside
OpenPAM (note that this is different from Linux-PAM)
as used in FreeBSD
a FreeBSD 8.1 machine. The bug is that a program,
namely kcheckpass, which is suid to root, is calling
pam_start() with a user provided argument which makes
the PAM stack parse user owned
config files which ends in loading of user
provided DSO's. WTF?!
Interestingly, OpenPAM recently introduced a filter for
the service name via
http://trac.des.no/openpam/changeset/478/trunk/lib/openpam_configure.c
commit but I dont think that any BSD or so vendor is
aware of it.
A really trivial PoC exploit can be found here.
[Update:] Solaris is not using OpenPAM (at least the OpenSolaris
version I checked), but I could not find code that strips
off certain character sequences. As the PAM setup is different
from the /etc/pam.d we know it is possible that there are no
consequences if the service argument is not filtered.
However a lot of BSD derivates
use OpenPAM and OSX as well. The question is whether one can
find a vector different than the kcheckpass which is usually
found with all KDE3 and KDE4 installs.
If you can confirm vulnerability on any Solaris or non-FreeBSD
machine, please let me know. Also if you found out how OSX
can be exploited this way.
Posts
4 comments:
The bug is in kcheckpass, not in OpenPAM. It should not allow the user to specify which policy to use.
BTW, I'm pretty sure FreeBSD's libpam maintainer is aware of recent changes in OpenPAM, but he has a policy of only importing official releases unless there is a critical bug that needs fixing.
Hi DES,
Indeed thats a point. Actually
such vulnerabilities exist because
its unclear who is responsible
for input cleaning.
FWIW, The same bug exists in squid and
squid3 package.
BTW, I'd like your opinion on this patch, which should alleviate the issue. I'm considering introducing similar restrictions on policy files.
Changesets 496 and 497 should further improve matters.
Post a Comment