** 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
* 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]
Created attachment 180392 [details, diff]
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.
(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.
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.
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.
Pushed 3.13 as unstable into tree. I'd suggest to stable this one - what do you think?
(In reply to comment #15)
> Pushed 3.13 as unstable into tree. I'd suggest to stable this one - what do you
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?
Arches, please test and mark stable:
Target keywords : "amd64 ppc sparc x86"
Already stabled : "amd64 x86"
Missing keywords: "ppc sparc"
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.
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.
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.
Do you have another solution for the security issue? If you do have - have you already discussed the patch with upstream?
(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. ***