Date: Wed, 28 Dec 2011 03:25:09 +0400 From: Solar Designer <solar@...nwall.com> To: Jeff Mitchell <mitchell@....org> Cc: oss-security@...ts.openwall.com, cve@...re.org, ossi@....org Subject: Re: Disputing CVE-2011-4122 On Mon, Dec 26, 2011 at 11:39:55PM -0500, Jeff Mitchell wrote: > 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). Sure, but is it valid and not a vulnerability when installing a package (containing kcheckpass) unexpectedly (for a sysadmin) lets any user on the system invoke any of the configured PAM stacks, some of which may have side-effects? I think it is not valid, and I think it is a vulnerability on its own, albeit a relatively minor one, regardless of PAM's pam_start() service name directory traversal possibility or lack thereof. In other words, I say that kcheckpass is vulnerable (in this different way) even on systems that don't use OpenPAM (or that use fixed OpenPAM). > 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. Like I said before, this definitely makes some sense to me. The service name was not supposed to be user input, though. Normally, the same application provides the service name and cares about the authentication result, so it would not reasonably let the user choose the service name arbitrarily (as that would also let the user affect the authentication result in possibly unintended ways). We have a rare exception here, where the authentication result actually does not matter to kcheckpass itself, but matters to another application - one in control of the supplied service name. OK, that's a peculiar exception and a somewhat valid use case, and I fully support the OpenPAM hardening change that this prompted. > 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. We need two CVE ids then - one for OpenPAM, the other for the kcheckpass issue (namely, letting a user run arbitrary PAM stacks, including those that a sysadmin may never have intended for the user to be able to run). Makes sense? Alexander
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.