Date: Mon, 26 Dec 2011 23:39:55 -0500 From: Jeff Mitchell <mitchell@....org> To: Solar Designer <solar@...nwall.com> CC: oss-security@...ts.openwall.com, cve@...re.org, ossi@....org Subject: Re: Disputing CVE-2011-4122 On 12/23/2011 06:22 PM, Solar Designer wrote: > On Wed, Dec 07, 2011 at 09:26:44AM -0500, Jeff Mitchell wrote: >> I've been asked by the kcheckpass maintainer to lodge a dispute of >> CVE-2011-4122. >> >> As explained in the blog entry linked from the CVE, the problem is >> that neither kcheckpass nor OpenPAM validate the 'service_name' input >> argument of pam_start(). This hole can be used to make PAM load >> arbitrary shared libraries, which can be used to execute arbitrary code >> as root, as kcheckpass is setuid root. > > Besides loading of arbitrary shared libraries due to the OpenPAM > peculiarity, doesn't this kcheckpass feature allow a user to specify an > arbitrary PAM service name that is actually valid on the system, not > limited to PAM services intended for use by KDE? Isn't that a > vulnerability of itself? While kcheckpass itself doesn't grant access > to any resource, an alternate PAM stack (maybe only intended for use by > a specific service) might have modules with side-effects. > > To me, kcheckpass looks poorly designed in letting the invoking user > specify an arbitrary PAM service name. Instead, the service name should > either be obtained from a trusted place or it should be checked against > a trusted whitelist. > > For example, passwd(1) from SimplePAMApps does the latter: it has a > command-line option to specify a PAM service name suffix (which it'd > append to "passwd"), but the suffix must be whitelisted in > /etc/security/passwd.conf. <snip> My understanding -- and I'm not the maintainer, so I'm typing this based on my own understanding of the program and this problem from my talks with the maintainer, whom I've CCed -- is that at a simple level it can be used for normal PAM user authentication, but that it's also designed to provide a simple interface to do arbitrary kinds of PAM authentication depending on user/application needs. For instance, you when invoking kcheckpass you can not only specify the PAM service name but can also choose whether to use a stdin-based interface or a file descriptor handle to communicate with it. So you get access to authenticate with PAM for PAM services that use passwords but without having to interface directly with PAM libraries. This kind of behavior is not restricted within OpenPAM itself, and there is nothing in the documentation that indicates that such external accessor programs need to perform any sort of input sanitation on the service name field. Sure -- ideally you want such programs performing some kind of sanitation, but then you have to decide, rather than the application developer using your accessor program, what is appropriate and what isn't. There are some obvious candidates but a lot of choices that would be harder. So kcheckpass, at least for the moment, punts all of this down to OpenPAM. Is it *nice*? No. Is it *valid*? Yes, unless OpenPAM changes its programming guide to require sanity checking of inputs at a higher level (and then it should still do its own checking anyways). That's the basis for the maintainer wanting to challenge this CVE. Even if everyone agrees that kcheckpass should do some kind of filtering of service names, the fact remains that OpenPAM should have been doing its own sanity checking anyways (since it should never simply trust user input), and OpenPAM wasn't. If it wasn't kcheckpass that exposed this problem, it would eventually have been something else. I'll happily pass your comments along to the kcheckpass maintainer, and he indicated to me during our discussions that some level of filtering would probably be appropriate, but this CVE is due to OpenPAM's lack of sanity checking and blaming the program that exposes it via valid (if ugly) usage scenarios is misguided. Thanks, Jeff Download attachment "signature.asc" of type "application/pgp-signature" (260 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.