pam-krb5 security advisory (3.12 and earlier)

                 pam-krb5 security vulnerability

Vulerability type: Local privilege escalation, local file overwrite
Versions affected: All versions prior to 3.13
Versions fixed: 3.13 and later
Reported: 2009-01-29
Public announcement: 2009-02-11
CVE IDs: CVE-2009-0360, CVE-2009-0361

A security vulnerability in pam-krb5 allowing overwrite and chown of
arbitrary files via Solaris su was discovered by Derek Chan and reported
by Steven Luo on 2009-01-29. Subsequent code auditing for behavior in
setuid applications uncovered another, more general and more serious bug
that could result in privilege escalation.

This advisory is only for my pam-krb5 module, as distributed from my web
site and packaged by Debian, Ubuntu, and Gentoo. These vulnerabilities
will likely also affect any PAM modules derived from mine, but I'm not
personally aware of any such modules in widespread use. The Red Hat,
Sourceforge, and Solaris pam_krb5 and pam_krb5afs modules have completely
different lineages and code and would need to be checked separately for
the presence or absence of these problems. I urge all Kerberos PAM module
developers to check their modules for similar problems.

The following two vulnerbilities are present in all versions of my
pam-krb5 module prior to 3.13:

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.

I'm not aware of any exploits in the wild for either problem, but I have
working exploits for both. An exploit of the first vulnerability is
straightforward for anyone with knowledge of Kerberos. An exploit for the
second vulnerability requires identifying an application that uses the
vulnerable PAM calling sequence but is completely trivial once such an
application has been identified.

These problems have been corrected in pam-krb5 3.13, available from:

http://www.eyrie.org/~eagle/software/pam-krb5/

Direct download links to the release and the PGP signature of the release:

http://archives.eyrie.org/software/kerberos/pam-krb5-3.13.tar.gz
http://archives.eyrie.org/software/kerberos/pam-krb5-3.13.tar.gz.asc

pam-krb5 was released as the libpam-krb5 package with Debian 4.0 (etch).
These vulnerabilities have been fixed in the 2.6-1etch1 version of the
libpam-krb5 Debian package for Debian 4.0. They have also been fixed in
the 3.11-4 package for the upcoming Debian 5.0 (lenny) release and for
Debian unstable (sid).

pam-krb5 linked with the Heimdal Kerberos implementation was also released
as the libpam-heimdal package with Debian 4.0 (etch). This package is not
vulnerable to the first problem (CVE-2009-0360). The second problem
(CVE-2009-0361) has been fixed in the 2.5-1etch1 version of the
libpam-heimdal Debian package for Debian 4.0 and in the 3.10-2.1 version
for the upcoming Debian 5.0 (lenny) release and Debian unstable (sid).

Please accept my personal apologies for these vulnerabilities. The first
vulnerability in particular was an error I should have known about and
fixed some time previous. I even followed a BUGTRAQ discussion of a
closely related problem with Kerberos authentication in sudo, did some
investigation at the time, and apparently forgot or misremembered the
results of my investigation.

–
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/&gt;