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
Created attachment 316461 [details]
Patch from nalin
Can you provide a nice (easy) example reproducer so I can pass it along with the patch to vendor-sec?
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.
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.
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.
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.
This issue was addressed in:
Red Hat Enterprise Linux:
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.