Date: Mon, 2 Jan 2012 13:15:23 +0100 From: Oswald Buddenhagen <ossi@....org> To: Solar Designer <solar@...nwall.com> Cc: Jeff Mitchell <mitchell@....org>, oss-security@...ts.openwall.com, cve@...re.org Subject: Re: Disputing CVE-2011-4122 On Wed, Dec 28, 2011 at 03:25:09AM +0400, Solar Designer wrote: > 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 pondered this possibility when i initially added the override parameter to kcheckpass, but i couldn't come up with anything usefully exploitable - it would have to be some right which is granted to the user *only* by this particular service - but not full logins. this seems a bit far-fetched. so while you have a valid point in principle, it doesn't seem particularly relevant for desktop systems. fwiw, linux-pam's pam_unix has an own setuid helper for shadow pw verification for some time now. most services don't actually need root for authentication at all. consequently, it is usually not useful to install kcheckpass setuid root at all, which makes this whole discussion somewhat irrelevant in the first place (except that the upstream makefiles will still try to install with setuid root).
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.