** Please note that this issue is confidential and no information should be disclosed until it is made public, see "Whiteboard" for a date ** Josh Bressers writes: Stéphane Bertin reported a flaw to us in the way pam_krb5 handles the existing_ticket option. pam_krb5 fails to verify that the user in question has proper permissions to use an existing credential cache. 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 : "existing_ticket 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 krb5cc_0_XXXXX. 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 !!!! Here are the instructions our Nalin provided me for easy reproduction: 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.
mueli, cardoe, are you guys maintaining this? If so, please prepare an updated ebuild applying the patch and attach it to this bug. Do not commit anything to CVS. We will do prestable testing on this bug.
Created attachment 165862 [details, diff] pam_krb5-2.3.1-ccacheperms.patch
I'd say I'll take it ... g, mueli
This patch and the bug report are related to the Red Hat sources at http://people.redhat.com/nalin/pam_krb5/ but we are providing the implementation of Russ Allbery at http://www.eyrie.org/~eagle/software/pam-krb5/. Any instructions for further procedure? g, mueli
This bug is now public: http://rhn.redhat.com/errata/RHSA-2008-0907.html
(In reply to comment #4) > This patch and the bug report are related to the Red Hat sources at > http://people.redhat.com/nalin/pam_krb5/ but we are providing the > implementation of Russ Allbery at > http://www.eyrie.org/~eagle/software/pam-krb5/. > > Any instructions for further procedure? g, mueli Considering that we are using an independent product with its own codebase, it seems this issue does not affect us. We might want to verify our pam_krb does not suffer from a similar issue, but I do not have the capacity to do that now. mueli, and your new team member, how do you feel about that? Otherwise we'll just close this bug.
I'd say we can close this bug. We can't even reproduce the problem with our codebase because we don't have a "existing_ticket" pam option - which IMHO is absolutely against the kerberos principle ;) You can prove by grep "existing_ticket" options.c in our codebase. This code is responsible for parsing the options. greets, mueli
Good enough for me, thanks.
