Bug 461960 (CVE-2008-3825)

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:

Severity:

medium

Docs Contact:

Priority:

medium

Version:

unspecified

CC:

jlieskov, kreilly, nalin, security-response-team, stephane.bertin

Target Milestone:

---

Keywords:

Security

Target Release:

---

Hardware:

All

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2008-10-04 12:18:04 UTC

Type:

---

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Bug Depends On:

462112, 462113

Bug Blocks:

Attachments:

Description	Flags
Patch from nalin	none

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

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:
  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.