Bugzilla Bug 257075

** 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 an attachment (id=180390) [details]
pam_krb5-bug257075.patch

Created an attachment (id=180392) [details]
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 an attachment (id=180571) [details]
new pam_krb5 ebuild

Created an attachment (id=180573) [details]
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. ***