[2287] in Kerberos-V5-bugs
Re: telnet/51: telnetd requires auth negotiation to be complete before term set
daemon@ATHENA.MIT.EDU (schemers@stanford.edu)
Fri Oct 4 01:20:49 1996
Date: Thu, 3 Oct 1996 22:20:31 -0700 (PDT)
From: schemers@stanford.edu
To: Sam Hartman <hartmans@MIT.EDU>
Cc: schemers@stanford.edu, krb5-bugs@MIT.EDU, krb5-bugs-redist@MIT.EDU
In-Reply-To: <9610040404.AA01795@starkiller.MIT.EDU>
Sam Hartman writes:
>
> The policy decision was made because no session state should
> be established before authentication. In the case of term, I cannot
> think of any case where it creates a security problem, but in other
> cases it does create a security problem.
>
> However, as demonstrated by the following dump of telnet
> options, the client generally does not send the terminal type until
> prompted by the server. I suspect your mainframe is violating the
> spec in this respect but would have to ponder the appropriate RFCs for
> a while to be sure.
Since the terminal type option came out before the authentication
options (which looks like it did after a quick scan of the rfc index),
I don't see how it could be violating any rfcs.
Here is the dump from the mainframe to the un-modified v5b7 telnetd, which
has debugging turned on:
ommand> telnet slapshot
Escape character (to suspend telnet) is 'Ctrl-]'.
td: send do AUTHENTICATION
td: recv do SUPPRESS GO AHEAD
td: send will SUPPRESS GO AHEAD
td: recv will SUPPRESS GO AHEAD
td: send do SUPPRESS GO AHEAD
td: recv do ECHO
td: send will ECHO
td: recv will TERMINAL TYPE
td: send do TERMINAL TYPE
td: recv wont AUTHENTICATION
td: send will ENCRYPT
td: send do ENCRYPT
td: send do TSPEED
td: send do XDISPLOC
td: send do NEW-ENVIRON
td: send do OLD-ENVIRON
td: recv suboption TERMINAL-TYPE IS "VT100"
An environment option was sent before authentication negotiation completed.
This may create a security hazard. Connection dropped.
Hum. The strange thing is the standard Solaris telnet client works
with the telnetd:
td: send do AUTHENTICATION
td: recv do SUPPRESS GO AHEAD
td: send will SUPPRESS GO AHEAD
td: recv will TERMINAL TYPE
td: send do TERMINAL TYPE
td: recv will NAWS
td: send do NAWS
td: recv will TSPEED
td: send do TSPEED
td: recv will LFLOW
td: send do LFLOW
td: recv will LINEMODE
td: send dont LINEMODE
td: recv will NEW-ENVIRON
td: send do NEW-ENVIRON
td: recv do STATUS
td: send will STATUS
td: recv wont AUTHENTICATION
td: send will ENCRYPT
td: send do ENCRYPT
td: send do XDISPLOC
td: send do OLD-ENVIRON
td: recv suboption NAWS 0 80 (80) 0 40 (40)
td: recv dont ENCRYPT
td: recv wont ENCRYPT
td: recv wont XDISPLOC
td: recv wont OLD-ENVIRON
td: recv suboption TERMINAL-SPEED IS 9600,9600
td: recv suboption NEW-ENVIRON IS VAR "PRINTER" VALUE "bouquet"
td: recv suboption TERMINAL-TYPE IS "VT100"
td: send do ECHO
td: recv wont ECHO
td: send will ECHO
UNIX(r) System V Release 4.0 (slapshot.stanford.edu) (pts/10)
Ahhh.. I think I see what is going on. In looking at telentd.c,
auth_negotiated=1 is set after encryption is negotiated. (I think :-)
If you look at the mainframe client, it sends back the terminal type
before it sends back "dont ENCRYPT". That seems to be the problem.
Maybe "auth_negotiated" should be set to 1 after the server gets
back "wont AUTHENTICATION"?? Is the client supposed to be sending
back a "dont ENCRYPT" sooner? I'm not really sure, in any case,
it seems little overly restrictive in the case of some options,
like terminal type.
> Because I don't see a security issue involved in terminal type
> being sent before authentication, I can probably be convinced to
> remove the check from the MIT tree. However, I am somewhat reluctant
> to do so because I do believe the client is behaving improperly, and
> there really is no good reason to do session parameter negotiation
> before authentication and encryption.
I guess you mean (or should mean) before "auth and encrypt negotiation",
as it looks like you can send that stuff after rejecting both authentication
and encryption.
I certainly don't claim to know telnet enough to know if the client
is doing something wrong, but it looks to me like the client is behaving.
thanks, roland
