Ticket History #6967: Kerberos weakness

# Fri Sep 30 13:09:01 2011 "Shelby, James" <James.Shelby@nrel.gov> - Ticket created

From:	"Shelby, James" <James.Shelby@nrel.gov>
To:	"'krb5-bugs@mit.edu'" <krb5-bugs@mit.edu>
Date:	Thu, 29 Sep 2011 12:23:21 -0600
Subject:	Kerberos weakness

Download (untitled) / with headers
text/plain 706B

Download (untitled) / with headers
text/html 5.1KiB

Is there a reason that the current Kerberos allows a KRB5CCNAME file to be created instead of being in memory? This appears to be a weak link in the security of the Kerberos protocol as the file can be moved from system and allow passwordless access to resources the account has access to. If crafted correctly a compromised system could modify the /etc/krb5.conf file to allow maximum ticket life and renewal then capture keys on the multiuser/compromised system and allow the keys to be moved from system to system with full access. Shouldn’t the Kerberos tickets be stored in protected memory somehow or in a more secure way?

James Shelby

NREL - Linux Desktop Integrations

(303) 275-3298 Desk/Cell

# Fri Sep 30 14:42:58 2011 Russ Allbery <rra@stanford.edu> - Correspondence added

From:	Russ Allbery <rra@stanford.edu>
To:	rt@krbdev.mit.edu
Subject:	Re: [krbdev.mit.edu #6967] Kerberos weakness
Date:	Fri, 30 Sep 2011 11:42:57 -0700
RT-Send-Cc:

Download (untitled) / with headers
text/plain 980B

Shelby@krbdev.mit.edu, James " via RT" <rt-comment@krbdev.mit.edu> writes:

Show quoted text

> Is there a reason that the current Kerberos allows a KRB5CCNAME file to
> be created instead of being in memory? This appears to be a weak link
> in the security of the Kerberos protocol as the file can be moved from
> system and allow passwordless access to resources the account has access
> to.

It's nice to be able to share ticket caches between processes (where nice
really means "mandatory" for most Kerberos use cases).

On Linux, you can use the KEYRING:* ticket cache type, which uses the
kernel keyring and may have more of the behavior that you're looking for,
although you still have the problem that anyone with access to read the
ticket cache can still copy it.

Memory ticket caches are of course supported, but aren't widely used
because of all the limitations involving passing tickets to subprocesses.

--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>

# Fri Sep 30 14:45:41 2011 "Shelby, James" <James.Shelby@nrel.gov> - Comments added

From:	"Shelby, James" <James.Shelby@nrel.gov>
To:	"'rt-comment@krbdev.mit.edu'" <rt-comment@krbdev.mit.edu>
Date:	Fri, 30 Sep 2011 12:45:40 -0600
Subject:	RE: [krbdev.mit.edu #6967] Kerberos weakness
RT-Send-Cc:

Download (untitled) / with headers
text/plain 1.3KiB

Thanks. Ideally that would work similar to mac by using the keyring. I just need to read the documentation on removing the /tmp/krb5cc file as it exploits the entire network for the duration of the ticket life.

Show quoted text

-----Original Message-----
From: Russ Allbery via RT [mailto:rt-comment@krbdev.mit.edu]
Sent: Friday, September 30, 2011 12:43 PM
To: Shelby, James
Subject: Re: [krbdev.mit.edu #6967] Kerberos weakness

Shelby@krbdev.mit.edu, James " via RT" <rt-comment@krbdev.mit.edu> writes:

> Is there a reason that the current Kerberos allows a KRB5CCNAME file to
> be created instead of being in memory? This appears to be a weak link
> in the security of the Kerberos protocol as the file can be moved from
> system and allow passwordless access to resources the account has access
> to.

It's nice to be able to share ticket caches between processes (where nice
really means "mandatory" for most Kerberos use cases).

On Linux, you can use the KEYRING:* ticket cache type, which uses the
kernel keyring and may have more of the behavior that you're looking for,
although you still have the problem that anyone with access to read the
ticket cache can still copy it.

Memory ticket caches are of course supported, but aren't widely used
because of all the limitations involving passing tickets to subprocesses.

--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>

# Tue Jul 03 15:18:29 2012 tlyu (Taylor Yu) - Status changed from 'new' to 'resolved'

# Tue Jul 03 15:18:29 2012 tlyu (Taylor Yu) - Tags nochange added