pam-krb5 2009-02-11 Advisory

Vulnerability 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 vulnerabilities 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/

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.

Last spun 2022-02-06 from thread modified 2013-01-04