Bug 461960 (CVE-2008-3825) - CVE-2008-3825 pam_krb5 existing_ticket permission flaw
Summary: CVE-2008-3825 pam_krb5 existing_ticket permission flaw
Alias: CVE-2008-3825
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 462112 462113
TreeView+ depends on / blocked
Reported: 2008-09-11 17:16 UTC by Josh Bressers
Modified: 2021-11-12 19:52 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-10-04 12:18:04 UTC

Attachments (Terms of Use)
Patch from nalin (7.67 KB, patch)
2008-09-11 17:23 UTC, Josh Bressers
no flags Details | Diff

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2008:0907 0 normal SHIPPED_LIVE Moderate: pam_krb5 security update 2008-10-02 13:59:55 UTC

Description Josh Bressers 2008-09-11 17:16:28 UTC
This bug was reported to us by Stéphane BERTIN.

The pam_krb5 module does not verify that the user has permission to read from the credential cache via the existing_ticket option.

From the mail Stéphane sent:

I failed to open SSH session with existing_ticket option.

I used these options to configure pam_krb5 :
auth sufficient pam_krb5.so try_first_pass minimum_uid=1
use_shmem=sshd existing_ticket validate=sshd debug


Extract from manual page :
tells pam_krb5.so to accept the presence of pre-existing Kerberos
credentials provided by the calling application in the default
credential cache as sufficient to authenticate the user, and to skip any
account management checks.
DANGER! Unless validation is also in use, it is relatively easy to
produce a credential cache which looks "good enough" to fool pam_krb5.so."

I use validate=sshd like it is recommended but it seems danger is around ...

I notice two things :
1) the module try twice to get credential see logs "trying existing
credentials" but don't try with user password and the session failed to
be opened. (that's why I have written the bug report)

2) User try to open SSH session so he doesn't already have credentials
and his variable KRB5CCNAME is not defined. By default module try to get
credentials on file /tmp/krb5cc_0. The root credential file !!!
I don't know why but root credential file doesn't have the same format

So if root ask a ticket for user TEST and get credential what happens ...
If you know which credential is used by root you can open a session
without to know password !!!!


Red Hat would like to thank Stéphane Bertin for responsibly disclosing this

Comment 1 Josh Bressers 2008-09-11 17:23:16 UTC
Created attachment 316461 [details]
Patch from nalin

Comment 2 Josh Bressers 2008-09-11 17:26:06 UTC

Can you provide a nice (easy) example reproducer so I can pass it along with the patch to vendor-sec?


Comment 3 Nalin Dahyabhai 2008-09-11 17:52:41 UTC
As the victim user, obtain a Kerberos TGT.

In the PAM configuration for "su", set the "existing_ticket" option by adding it as a parameter for the module when it's called to authenticate the user.  (If you're using 2.2.22 or later, you can alternately set "existing_ticket = su" in the "pam" subsection of the "appdefaults" section of krb5.conf.)

As the malicious user (who is presumably not able to read the victim's credential cache directly), set the KRB5CCNAME environment variable to point to the victim user's credential cache, and then attempt to use "su" to switch to the victim user's account (if you're prompted for a password by another module which is called before pam_krb5.so is called, you can supply it with any value).

The module will read the victim's TGT from the victim's credential cache and accept it, even if the malicious user wouldn't ordinarily have access to the victim's credentials.

Comment 4 Stéphane BERTIN 2008-09-12 15:43:53 UTC

I have tested the patch.
It partially solve the bug. The exploitation of the bug with su/sudo is
no more possible.
The module do not bypass restriction access on TGT file.

But if this option is configured for sshd the exploitation is still
possible (like describe in my post).
It is possible to have access on a system just with information of
credential name used by root.
The difference now is that with this access the user has not access to
TGT file (owner is root) so he cannot have access to TGS.
The probability for exploitation is very low because it is necessary :
to have existing_ticket option for SSH, root has a valid TGT and to know
the credential used by root.

At the end, please do not forget to back port the patch for previous release of pam_krb5 (included in RHEL5 and previous).
And release updated rpm on RHN.

Comment 6 Tomas Hoger 2008-10-01 19:22:12 UTC
Lifting embargo.

Comment 7 Fedora Update System 2008-10-03 22:34:13 UTC
pam_krb5-2.2.18-2.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 8 Fedora Update System 2008-10-03 22:36:09 UTC
pam_krb5-2.3.0-2.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 9 Red Hat Product Security 2008-10-04 12:18:04 UTC
This issue was addressed in:

Red Hat Enterprise Linux:


Comment 10 Josh Bressers 2008-10-07 12:07:05 UTC
Please note this flaw does not affect versions of pam_krb5 as shipped in Red Hat Enterprise Linux 2.1, 3, or 4.

Those versions of pam_krb5 do not support the existing ticket option.

Note You need to log in before you can comment on or make changes to this bug.