[940] in Kerberos_V5_Development
dealing with rsh command-line authentication
daemon@ATHENA.MIT.EDU (Sam Hartman)
Tue Oct 31 00:49:39 1995
Date: Tue, 31 Oct 1995 01:49:28 -0400
From: Sam Hartman <hartmans@MIT.EDU>
To: krbdev@MIT.EDU
Currently, rshd does a fairly good job of authenticating a
user, but doesn't do a good job of authenticating their request. I
realize krshd is to be desupported, but honestly, I don't see that
happening just yet; it's going to take a lot of work before telnetd is
a plug-in replacement for rshd.
Anyway, I believe I have a way of making it secure without
breaking backward compatability--it involves changing the protocol
somewhat, but AFAIK rsh isn't standardized to the extent that any
formal process is required.
I propose that the kcmd function include a checksum of the
command line by using the indata argument to krb5_mk_req (well,
krb5_compat_sendauth, but the argument exists). This would cause the
authenticator sent over the net to contain a checksum. This
checksumwould get stuff into the auth context on the remote end. n
old krshd would ignore the checksum, but a new krshd could verify a
checksum if it exists, and execute only command lines that sum
correctly. Since the command line indicates the client's encryption
preference, this would allow the client to securely negotiate
encryption.
Since you can't pull fields out of an authenticator and expect
it to decrypt correctly, an active attack cannot try to substitute an
authenticator without a checksum for one containing a checksum. Thus,
from what I can tell, if a client only uses the new rsh and only
connects to hosts with the new rshd, an attacker cannot:
1) Force a different command line to be executed.
2) Force an encrypted session to be non-encrypted
3) Use TCP sequence number guessing attacks to take over a
encryp[encrypted stream successfully without breaking the session key.
--Sam
