Skip Menu |
 

Download (untitled) / with headers
text/plain 17.8KiB
From schemers@slapshot.stanford.edu Thu Oct 3 17:34:58 1996
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id RAA16539 for <bugs@RT-11.MIT.EDU>; Thu, 3 Oct 1996 17:34:58 -0400
Received: from slapshot.Stanford.EDU by MIT.EDU with SMTP
id AA24080; Thu, 3 Oct 96 17:34:54 EDT
Received: (from schemers@localhost) by slapshot.stanford.edu (8.7.6/8.7.3) id OAA05483; Thu, 3 Oct 1996 14:34:43 -0700 (PDT)
Message-Id: <199610032134.OAA05483@slapshot.stanford.edu>
Date: Thu, 3 Oct 1996 14:34:43 -0700 (PDT)
From: schemers@stanford.edu
To: krb5-bugs@MIT.EDU
Subject: telnetd requires auth negotiation to be complete before term set

Show quoted text
>Number: 51
>Category: telnet
>Synopsis: telnetd requires auth negotiation to be complete before term set
>Confidential: no
>Severity: serious
>Priority: low
>Responsible: hartmans
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Thu Oct e 17:35:01 EDT 1996
>Last-Modified: Thu Sep 13 21:33:39 EDT 2001
>Originator: schemers@stanford.edu
>Organization:
>Release: beta-7
>Environment:
>Description:
Hi. We are running the telnetd from v5b7 on our Solaris systems and
noticed that our mainframe could not connect to any systems running
this telnetd (I actually like this feature, but some people are
complaining :-). They would connect, but the connection would immediately
close.

I tracked it down to telnetd/state.c:

case TELOPT_TTYPE: { /* Yaaaay! */
static char terminalname[41];

if (his_state_is_wont(TELOPT_TTYPE)) /* Ignore if option disabled */
break;
sb_auth_complete();

It turns out that the mainframe telnet client is sending the terminal type
before authentication. I think I've also heard reports of other
clients doing this as well. I realize why the sb_auth_complete() calls
were added, but is there really any security problem with setting the
terminal type before authentication? I couldn't think of one.
Is this a policy decision or does some telnet RFC specify that the
terminal type option can't be set before authentication?

For now I just commented out the call (just this one, I left the
others in). I was also curious if anyone else has reported problems
with other telnet clients and the sb_auth_complete() calls.

thanks, roland


Show quoted text
>How-To-Repeat:
>Fix:
>Audit-Trail:

Responsible-Changed-From-To: gnats-admin->hartmans
Responsible-Changed-By: hartmans
Responsible-Changed-When: Thu Oct 3 23:51:33 1996
Responsible-Changed-Why:


From: Sam Hartman <hartmans@MIT.EDU>
To: schemers@stanford.edu
Cc: krb5-bugs@MIT.EDU, krb5-bugs-redist@MIT.EDU
Subject: Re: telnet/51: telnetd requires auth negotiation to be complete before term set
Date: Fri, 4 Oct 1996 00:04:11 -0400

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.


athena% add krb5
add krb5
athena% /mit/krb5/bin/telnet -xa
/mit/krb5/bin/telnet -xa
Show quoted text
telnet> set options
set options
Will show option processing.
Show quoted text
telnet> open tertius
open tertius
Trying 18.245.0.72...
Connected to tertius.MIT.EDU.
Escape character is '^]'.
SENT WILL AUTHENTICATION
SENT DO ENCRYPT
SENT WILL ENCRYPT
SENT DO SUPPRESS GO AHEAD
SENT WILL TERMINAL TYPE
SENT WILL NAWS
SENT WILL TSPEED
SENT WILL LFLOW
SENT WILL LINEMODE
SENT WILL NEW-ENVIRON
SENT DO STATUS
...
RCVD IAC SB AUTHENTICATION SEND KERBEROS_V4 CLIENT|MUTUAL KERBEROS_V4 CLIENT|ONE-WAY
[ Trying KERBEROS4 ... ]
SENT IAC SB AUTHENTICATION NAME "hartmans"
...
RCVD WILL ENCRYPT
SENT IAC SB ENCRYPT REQUEST-START
SENT IAC SB ENCRYPT SUPPORT DES_CFB64 DES_OFB64
RCVD DO ENCRYPT
...
RCVD WILL SUPPRESS GO AHEAD
RCVD DO TERMINAL TYPE
RCVD DO NAWS
RCVD DO TSPEED
RCVD DO LFLOW
RCVD DONT LINEMODE
RCVD DO NEW-ENVIRON
RCVD WILL STATUS
...
...
...
RCVD DO XDISPLOC
SENT WONT XDISPLOC
RCVD DO OLD-ENVIRON
SENT WONT OLD-ENVIRON
...
SENT IAC SB ENCRYPT REPLY DES_CFB64 CFB64_IV_OK
...
[ Kerberos V4 challenge successful ]
RCVD IAC SB ENCRYPT REPLY DES_CFB64 CFB64_IV_OK
SENT IAC SB ENCRYPT ENC_KEYID 0
RCVD IAC SB ENCRYPT ENC_KEYID 0
SENT IAC SB ENCRYPT DEC_KEYID 0
RCVD IAC SB ENCRYPT DEC_KEYID 0
SENT IAC SB ENCRYPT START
RCVD IAC SB ENCRYPT START
RCVD IAC SB TERMINAL-SPEED SEND
SENT IAC SB TERMINAL-SPEED IS 9600,9600
RCVD IAC SB NEW-ENVIRON SEND
SENT IAC SB NEW-ENVIRON IS VAR "USER" VALUE "hartmans" VAR "PRINTER" VALUE "nil"
RCVD IAC SB TERMINAL-TYPE SEND
SENT IAC SB TERMINAL-TYPE IS "UNKNOWN"


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.

--Sam


From: schemers@stanford.edu
To: Sam Hartman <hartmans@MIT.EDU>
Cc: schemers@stanford.edu, krb5-bugs@MIT.EDU, krb5-bugs-redist@MIT.EDU
Subject: Re: telnet/51: telnetd requires auth negotiation to be complete before term set
Date: Thu, 3 Oct 1996 22:20:31 -0700 (PDT)

Sam Hartman writes:
Show quoted text
>
> 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:

Show quoted text
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.

Show quoted text
> 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

From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Sam Hartman <hartmans@MIT.EDU>
Cc: schemers@stanford.edu, krb5-bugs@MIT.EDU, krb5-bugs-redist@MIT.EDU
Subject: Re: telnet/51: telnetd requires auth negotiation to be complete before term set
Date: Fri, 4 Oct 1996 09:52:28 -0400

Date: Fri, 4 Oct 1996 00:04:11 -0400
From: Sam Hartman <hartmans@MIT.EDU>

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.

I doubt it's a violation of the RFC. We could put in a explicit words
into the draft standard which defines the new telnet "I promise I will
encrypt" bit. If you're not encrypting, whether you assert the
telnet and environment variables before or after the authentication
doesn't really matter anyway.

This has the advantage that old clients who don't know about the "I
promise I will encrypt bit" won't lose.

- Ted

From: Sam Hartman <hartmans@MIT.EDU>
To: schemers@stanford.edu
Cc: Sam Hartman <hartmans@MIT.EDU>, krb5-bugs@MIT.EDU,
krb5-bugs-redist@MIT.EDU
Subject: Re: telnet/51: telnetd requires auth negotiation to be complete before term set
Date: 04 Oct 1996 17:51:15 -0400

Show quoted text
>>>>> "schemers" == schemers <schemers@stanford.edu> writes:

Show quoted text
schemers> Sam Hartman writes:
Show quoted text
>> 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.

Show quoted text
schemers> Since the terminal type option came out before the
schemers> authentication options (which looks like it did after a
schemers> quick scan of the rfc index), I don't see how it could
schemers> be violating any rfcs.

Sorry; I meant that it was violating RFCs by sending the
terminal type before the server sent the IAC SB terminal type SEND
command. See below.

Show quoted text
schemers> Hum. The strange thing is the standard Solaris telnet
schemers> client works with the telnetd:

I think the difference you don't see here is that your debug
only includes will/won't/do/don't options, not subcommands.

Quoting from RFC1091:


Once the two hosts have exchanged a WILL and a DO, the sender of the
DO TERMINAL-TYPE (the server) is free to request type information.
Only the server may send requests (IAC SB TERMINAL-TYPE SEND IAC SE)
and only the client may transmit actual type information (within an
IAC SB TERMINAL-TYPE IS ... IAC SE command). Terminal type
information may not be sent spontaneously, but only in response to a
request.

I suspect that your mainframe is spontaniously sending the
terminal type info. At any rate, I don't think our telnetd will ever
request that the client send terminal type until after authentication
negotiation is complete.

Show quoted text
schemers> Ahhh.. I think I see what is going on. In looking at
schemers> telentd.c, auth_negotiated=1 is set after encryption is
schemers> negotiated. (I think :-) If you look at the mainframe
schemers> client, it sends back the terminal type before it sends
schemers> back "dont ENCRYPT". That seems to be the problem.
schemers> Maybe "auth_negotiated" should be set to 1 after the
schemers> server gets back "wont AUTHENTICATION"??

This is reasonable so long as you accept the won't encrypt
when it comes in. It's important to note that once you have ended
authentication negotiation, you cannot accept a will authentication or
a will encrypt without carefully examining intervening options.

Show quoted text
schemers> Is the client
schemers> supposed to be sending back a "dont ENCRYPT" sooner? I'm
schemers> not really sure, in any case, it seems little overly
schemers> restrictive in the case of some options, like terminal
schemers> type.

Perhaps. I'll think about any possible consiquenceso of
proposed solutions.

Show quoted text
>> 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.

Show quoted text
schemers> I guess you mean (or should mean) before "auth and
schemers> encrypt negotiation", as it looks like you can send that
schemers> stuff after rejecting both authentication and
schemers> encryption.

Correct.

Show quoted text
schemers> thanks, roland

From: Sam Hartman <hartmans@MIT.EDU>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: Sam Hartman <hartmans@MIT.EDU>, schemers@stanford.edu, krb5-bugs@MIT.EDU,
krb5-bugs-redist@MIT.EDU
Subject: Re: telnet/51: telnetd requires auth negotiation to be complete before term set
Date: 04 Oct 1996 17:59:45 -0400

Show quoted text
>>>>> "Theodore" == "Theodore Y Ts'o" <tytso@MIT.EDU> writes:

Show quoted text
Theodore> Date: Fri, 4 Oct 1996 00:04:11 -0400 From: Sam
Theodore> Hartman <hartmans@MIT.EDU>

Show quoted text
Theodore> However, as demonstrated by the following dump of
Theodore> telnet options, the client generally does not send the
Theodore> terminal type until prompted by the server. I suspect
Theodore> your mainframe is violating the spec in this respect but
Theodore> would have to ponder the appropriate RFCs for a while to
Theodore> be sure.

Show quoted text
Theodore> I doubt it's a violation of the RFC. We could put in a
Theodore> explicit words into the draft standard which defines the
Theodore> new telnet "I promise I will encrypt" bit.
This would be useful. Basically, a server needs to be able to
(and should be required to) reject sensative options until it knows
whether the client will encrypt. If the server accepts a sensitive
option, it cannot then accept encryption.

Sensitive options should include X display, and both
environment options. They may also include things like terminal type,
terminal speed, etc. Also, future options like those needed for
rsh-style error redirection will almost certainly be sensitive.

As a side note, what convinced you that our current approach
is better to standardize on than Galvin's authencrypt option?

Show quoted text
Theodore> If you're
Theodore> not encrypting, whether you assert the telnet and
Theodore> environment variables before or after the authentication
Theodore> doesn't really matter anyway.

True, if you have a client that supports the encryption
promised bit or if you know for other reasons that the client will
never encrypt.

Show quoted text
Theodore> This has the advantage that old clients who don't know
Theodore> about the "I promise I will encrypt bit" won't lose.

I supose I could take an alternate approach to solve this and
refuse encryption once I had received a sensitive option.


Show quoted text
Theodore> - Ted

From: schemers@stanford.edu
To: Sam Hartman <hartmans@MIT.EDU>
Cc: krb5-bugs@MIT.EDU, krb5-bugs-redist@MIT.EDU
Subject: Re: telnet/51: telnetd requires auth negotiation to be complete before term set
Date: Fri, 4 Oct 1996 15:30:37 -0700 (PDT)

Sam Hartman writes:
Show quoted text
> >>>>> "schemers" == schemers <schemers@stanford.edu> writes:
> Quoting from RFC1091:
>
>
> Once the two hosts have exchanged a WILL and a DO, the sender of the
> DO TERMINAL-TYPE (the server) is free to request type information.
> Only the server may send requests (IAC SB TERMINAL-TYPE SEND IAC SE)
> and only the client may transmit actual type information (within an
> IAC SB TERMINAL-TYPE IS ... IAC SE command). Terminal type
> information may not be sent spontaneously, but only in response to a
> request.
>
> I suspect that your mainframe is spontaniously sending the
> terminal type info. At any rate, I don't think our telnetd will ever
> request that the client send terminal type until after authentication
> negotiation is complete.
>

Thanks, that is probably what is happening. I'll get a hold of someone
who might have access to the telnet source on the mainframe.

thanks, roland
Show quoted text
>Unformatted:
To: rt-comment@krbdev.mit.edu
Subject: [krbdev.mit.edu #51] Not a bug
Date: Sun, 3 Nov 2002 19:33:36 -0500 (EST)
From: hartmans@mit.edu (Sam Hartman)
RT-Send-Cc:


It seems that if you want the term negotiation protected you do
actually need to make this requirement.