CVE-2009-0360 When linked with MIT Kerberos, pam-krb5 did not use the correct API for initializing the Kerberos libraries in a setuid context. This meant the MIT Kerberos libraries would trust environmental variables to locate the Kerberos configuration. An attacker could exploit this to bypass authentication checks in setuid applications using PAM for authentication, resulting in privilege escalation. This vulnerability was not present if pam-krb5 was linked with the Heimdal Kerberos implementation. CVE-2009-0361 pam_setcred with PAM_REINITIALIZE_CREDS or PAM_REFRESH_CREDS is used to refresh existing credentials for a user, such as when releasing a locked screen. It therefore honors the existing KRB5CCNAME environment variable to locate the existing Kerberos credential cache. This means, however, that if those APIs were called by a setuid application without first calling PAM_ESTABLISH_CREDS or dropping privileges, pam-krb5 may overwrite and chown the file specified by KRB5CCNAME to an attacker. This PAM calling sequence is unusual, but it's known to be used by Solaris 10 su. pam-krb5 3.13 and later will log an error message and return success without taking any action when a program attempts to reinitialize credentials in a setuid context. sys-auth/pam_krb5-4.2 is in the tree since May 21st with no bugs against it. Please stabilize. Reproducible: Always
Please stabilize sys-auth/pam_krb5-4.3 since pam_krb5-4.2 is not longer in the tree. From the changelog: 23 Jul 2010; Diego E. Pettenò <flameeyes@gentoo.org> -pam_krb5-3.13.ebuild, -pam_krb5-4.2.ebuild: Remove older versions.
Green light from me.
Arches, please test and mark stable: =sys-auth/pam_krb5-4.3 Target keywords : "amd64 ppc sparc x86"
x86 stable
I think we are missing arm and sh arches from stable request: From the pam_krb5 changelog: 15 Aug 2010; Raúl Porcel <armin76@gentoo.org> pam_krb5-4.3.ebuild: Add ~sh 02 Aug 2010; Markus Meier <maekke@gentoo.org> pam_krb5-4.3.ebuild: add ~arm, bug #329585
amd64 done
(In reply to comment #5) > I think we are missing arm and sh arches from stable request: > The package was never stable there. If you want it stable on these arches, file a regular stablereq.
sparc stable
Marked ppc stable.
GLSA vote: YES
GLSA Vote: Yes, too; request filed.
This issue was resolved and addressed in GLSA 201412-08 at http://security.gentoo.org/glsa/glsa-201412-08.xml by GLSA coordinator Sean Amoss (ackle).
