** Please note that this issue is confidential and no information should be disclosed until it is made public, see "Whiteboard" for a date ** Russ Allbery wrote: The following two vulnerbilities are present in all versions of my pam-krb5 module prior to 3.13: * 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. * 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.
Russ provided us with both patches for git HEAD (probably to apply on 3.12) and 3.09/3.10. Please prepare an ebuild applying either of those patches (i.e. version bump or revision bump, your choice) and attach it to this bug. Do not commit anything to CVS! We will do prestable testing on this bug. I have a few more details that I would forward to anyone of you in CC working on this bug, so please shout out if you're there. Furthermore, do we other Kerberos-enabled PAM plugins (i.e. the sourceforge one?). I know we had before, just want to make sure we do not anymore.
Created attachment 180390 [details, diff] pam_krb5-bug257075.patch
Created attachment 180392 [details, diff] pam_krb5-3.9-bug257075.patch
I'd say that' my job as kerberos maintainer. Related to http://www.eyrie.org/~eagle/software/pam-krb5/ the latest stable release is still 3.12 (and not 3.13) therefore I'd say we provide a 3.12 release bump with the patch included. Give me some hours - I am visiting my family ATM. greets, mueli
(In reply to comment #4) > Related to http://www.eyrie.org/~eagle/software/pam-krb5/ the latest stable > release is still 3.12 (and not 3.13) Yep, 3.13 is coming out on Feb. 11 (the embargo date).
Created attachment 180571 [details] new pam_krb5 ebuild
Created attachment 180573 [details, diff] removed NEWS file from patch - simple to maintain over different releases
ebuild compiles on my environments and functionality is ok - security bug not tested by myself. I've renamed the patch and removed the NEWS file from the patch because this file is simply not patchable with one patch over multiple releases. Don't hesitate to tell me if you need something more. greets, mueli
BTW: I am not maintaining any other pam module for kerberos and I don't know of any other in our tree - but I might have missed some ... so if you know one more, please tell me!
Sry - clicking to fast
FWIW I have no idea about Kerberos, I can tell you that sys-libs/pam does not have any kerberos bits though.
Arch Security Liaisons, please test the attached ebuild and report it stable on this bug. Ebuild: =sys-auth/pam_krb5-3.12 Note you only need the last two atached files. Target keywords : "amd64 ppc sparc x86" CC'ing current Liaisons: amd64 : keytoaster, tester ppc : dertobi123 sparc : fmccor x86 : maekke, armin76
looks good on amd64/x86.
Public via http://thread.gmane.org/gmane.comp.encryption.kerberos.general/13398 mueli, please bump in the tree and commit straight to stable for the arches that responded here. We'll add the others afterwards.
Done. Pushed 3.13 as unstable into tree. I'd suggest to stable this one - what do you think? g, Michael
(In reply to comment #15) > Done. > > Pushed 3.13 as unstable into tree. I'd suggest to stable this one - what do you > think? Judging from the ChangeLog there are no relevant changes for users (allow building against older Heimdal, figure out libdir if kerberos does not provide pkgconfig), so I'm hesitant to cause upgrades for them and work for amd64/x86 again. However, this is at your discretion. But feel free to add ppc and sparc for either version to this bug. Also, can you please rename the patch to be pam_krb5-3.12-CVE-2009-0361-0362.patch or so, because right now it can be easily mistaken to be a patch for CVE-2009-0211 which would be a different issue (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0211). Thanks!
ACK - as we have already stabled on x86/amd64 let us finalize for 3.12 release. Renaming is done. sparc, ppc - could you please stable pam_krb5-3.12? greets, mueli
Arches, please test and mark stable: =sys-auth/pam_krb5-3.12 Target keywords : "amd64 ppc sparc x86" Already stabled : "amd64 x86" Missing keywords: "ppc sparc"
ppc done
CVE-2009-0360 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-0360): Russ Allbery pam-krb5 before 3.13, when linked against MIT Kerberos, does not properly initialize the Kerberos libraries for setuid use, which allows local users to gain privileges by pointing an environment variable to a modified Kerberos configuration file, and then launching a PAM-based setuid application. CVE-2009-0361 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-0361): Russ Allbery pam-krb5 before 3.13, as used by libpam-heimdal, su in Solaris 10, and other software, does not properly handle calls to pam_setcred when running setuid, which allows local users to overwrite and change the ownership of arbitrary files by setting the KRB5CCNAME environment variable, and then launching a setuid application that performs certain pam_setcred operations.
sparc stable
GLSA request filed.
now users need to kinit manually after unlocking their screens with expired credentials. we should really think about that effect of the patch. admins should be warned about this change of behavior.
Hi mastamind! Do you have another solution for the security issue? If you do have - have you already discussed the patch with upstream? Thx, mueli
(In reply to comment #24) > Hi mastamind! > > Do you have another solution for the security issue? If you do have - have you > already discussed the patch with upstream? > > Thx, mueli > Not sure if he got the reply since he was not cc'ed...
Any word on stabling 3.13?
Also, why is the patch named pam_krb5-3.12-CVE-2009-0361-0362.patch when it fixes CVE-2009-0360 and CVE-2009-0361?
Stabaling pam_krb5-3.13 should be fine - first commit was done on 2009-02-12. Is this soultion acceptable for the security team?
(In reply to comment #28) > Stabaling pam_krb5-3.13 should be fine - first commit was done on 2009-02-12. > Is this soultion acceptable for the security team? It does not impact this security bug, but fell free to request a regular stabling on another bug.
(In reply to comment #27) > Also, why is the patch named pam_krb5-3.12-CVE-2009-0361-0362.patch when it > fixes CVE-2009-0360 and CVE-2009-0361? > Just an error in the patch filename, nothing important. This was GLSA 200903-39, thanks everyone.
*** Bug 269008 has been marked as a duplicate of this bug. ***
