|Summary:||CVE-2008-3825 pam_krb5 existing_ticket permission flaw|
|Product:||[Other] Security Response||Reporter:||Josh Bressers <bressers>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||unspecified||CC:||jlieskov, kreilly, nalin, security-response-team, stephane.bertin|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-10-04 12:18:04 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||462112, 462113|
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 : "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 !!!! Acknowledgements: Red Hat would like to thank Stéphane Bertin for responsibly disclosing this issue.
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
nalin, Can you provide a nice (easy) example reproducer so I can pass it along with the patch to vendor-sec? Thanks
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
Nalin, 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
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: http://rhn.redhat.com/errata/RHSA-2008-0907.html Fedora: https://admin.fedoraproject.org/updates/F8/FEDORA-2008-8605 https://admin.fedoraproject.org/updates/F9/FEDORA-2008-8618
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.