Date: Sat, 24 Dec 2011 03:22:11 +0400 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Cc: Jeff Mitchell <mitchell@....org>, cve@...re.org Subject: Re: Disputing CVE-2011-4122 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. > One could assume that kcheckpass should do the validation. However, the > PAM documentation makes no mention of what a service name is supposed to > look like, and consequently it must be treated as opaque by the > application code. Therefore all validation must be expected to be done > by the library, and failure to do so must be seen as a bug in the > library exclusively. These are some valid points, but on the other hand giving an untrusted user full control over the PAM service name is so ridiculous that I can't blame a PAM library exclusively for not sanitizing this input. I think we'd set a bad precedent by saying that kcheckpass did everything right and only OpenPAM was at fault. I think that both need to be corrected. OpenPAM is already patched by now; is kcheckpass corrected in some way as well? http://security.freebsd.org/advisories/FreeBSD-SA-11:10.pam.asc > As a result, it is correct to list kcheckpass as an affected > application, but not as the origin of the vulnerability. My opinion is that the vulnerability originates in both places, or we can say that there's more than one vulnerability here. If I had to choose just one, I'd say that kcheckpass is more at fault than OpenPAM, and that OpenPAM's fix is a hardening measure, whereas kcheckpass needs to have its vulnerability fixed. I am not affiliated with either project; in fact, I am not even using KDE and OpenPAM normally. I am of a similar opinion regarding other cases where poorly written or misconfigured applications expose library interfaces that were never meant to be used on untrusted input. For example, the "glibc: timezone integer overflow" issue that was brought to this list earlier this month is in my opinion less of an issue than FTP server misconfiguration that makes the issue exploitable. That is, I'd rather assign CVE ids to FTP servers supporting chroot'ing into users' home directories without warning the server admins of the added root compromise risk inherent to such chroot'ing. Patching one attack vector in glibc does not eliminate that risk. http://www.openwall.com/lists/oss-security/2011/12/05/1 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.