[27576] in Kerberos
ticket steal possibility
daemon@ATHENA.MIT.EDU (Nikolai Tenev)
Wed Mar 21 07:25:41 2007
From: Nikolai Tenev <ntenev@orbitel.bg>
To: kerberos@mit.edu
Date: Wed, 21 Mar 2007 13:25:26 +0200
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200703211325.27008.ntenev@orbitel.bg>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Hi everyone,
I need some help or information source, to resolve one big (for me) problem
with MIT Kerberos.
Software:
CentOS 4.4
Kerberos 1.3.4
OpenSSH 3.9p1
The Network Description:
Used realm is @EXAMPLE.NET
Two servers from same realm and two clients from same realm but different
instances.
Server one has a host ticket host/server1.example.net@EXAMPLE.NET
Server two has a host ticket host/server2.example.net@EXAMPLE.NET
Client one has a client ticket client1/support@EXAMPLE.NET
Client two has a client ticket client2/developer@EXAMPLE.NET
On server one (server1) in krb5.conf I have a record:
auth_to_local = {
RULE:[2:$2](support)s/^.*$/root/
}
On server two (server2) in krb5.conf I have a record:
auth_to_local = {
RULE:[2:$2](support)s/^.*$/root/
RULE:[2:$2](developer)s/^.*$/root/
}
Both clients use ssh to conect to remote servers from their workstations.
According this client2 with realm client2/developer@EXAMPLE.NET can do login
as root on server2 but can not to do login on server1. Other user client1
with realm client1/support@EXAMPLE.NET can do login as root on both servers.
At this time everything is OK, and work as I expect.
The problem:
When client1 is logged in from his workstation1 as root on server2, the ticket
of client1 is forwarded and stored in file /tmp/krb5cc_0_r10108 owned by root
(root:root) and chmoded 600. But if in same time client2 make connection from
his workstation2 to server2 as root, he can read/copy ticket file
(/tmp/krb5cc_0_r10108 ) of client1 locally on his workstation2 and after that
is easy to represent self as client1 to server1 and grant root access before
ticket of client1 expire.
I search in Google for information how to resolve this problem and find three
common type of solutions.
1) To lock clients ticket by IP. Disadvantage is that some of users use their
laptops remotely from different networks, and they need addressless tickets.
2) To not forward tickets from client to server. This solution works, but for
now most of users use ssh-agent to forward their private keys from one
session to another (in example client1 make ssh to server1 and the from
server1 copy data to server2 via scp with his own ssh key). It's not good to
drop this possibility for them on condition that they find it as usable. But
supporting hundred ssh public keys on great number of servers is little hell
that I hope to resolve with kerberos.
3) One "alternative" solution is to make ticket available for a short-short
time (something about 2-3 seconds). But this not sound good enough to me.
Even if our corporate network speed allow this solution, we can not be sure
for others network. And even if the speed and times are perfect, if someone
know about this system weakness, he can find way to catch the ticket and make
ssh connection to another remote server with ticket that is steal. When ssh
connection is established, even if ticket expire, connection not drop.
Does anyone have some idea how to resolve this, or just link to useful
documentation ?
Thanks in advance !
--
Nikolai Tenev
Hosting Systems Support Engineer
Orbitel EAD - office Sofia
---------------------------------
Orbitel - Next Generation Telecom
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
