[8990] in bugtraq
Re: Bug
daemon@ATHENA.MIT.EDU (Jeffrey Hutzelman)
Fri Jan 8 13:35:43 1999
Date: Fri, 8 Jan 1999 02:47:26 -0500
Reply-To: Jeffrey Hutzelman <jhutz+@cmu.edu>
From: Jeffrey Hutzelman <jhutz+@CMU.EDU>
X-To: Curt Sampson <cjs@CYNIC.NET>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <Pine.NEB.4.02.9901031242130.6323-100000@epistolic.cynic.net>
> On Thu, 31 Dec 1998, Mr Spooty wrote:
>
> > This patch, along with the domestic version of the most recently
> > released telnet sources from Berkeley, are available via anonymous ftp
> > from net-dist.mit.edu in the directory /pub/telnet.
>
> As of Sun Jan 3 20:42:04 GMT 1999 the /pub/telnet directory is
> not world readable or searchable, and thus this patch cannot be
> downloaded.
>
> Does anyone have a copy of this patch, and perhaps more details on
> what it does?
I have no problem seeing into that directory, despite the unusual
permissions. The original post was little more than a copy of a
message sent by Ted Ts'o on 15-Feb-1995, nearly 4 years ago. The
gist of the bug, IIRC, was that the method used in the telnet client
to generate the session encryption key (the one used to actually encrypt
the data stream, not the session key in the Kerberos tickets) would
result in a key with bad parity 255/256 of the time. This, in turn,
could result in one of three situations, depending on how carefully
error checking was done at each end:
(a) Encryption negotiation fails, and the stream is unencrypted
(b) Encryption negotiation succeeds, and the stream is encrypted, but
using a highly predictable DES key schedule instead of one derived
from a randomly-chosen session key. This was the most dangerous
case, and I believe also the most common.
(c) Encryption negotiation succeeds, and the stream is encrypted,
but one end uses the bogus key schedule as in (b), while the other
uses a different schedule (IIRC, derived from the randomly-chosen
key, after forcing the parity bits). The result is that neither
end can communicate with the other.
The patch also appears to fix a fatal bug in the challenge-response
calculation, and to make changes to parsing of authentication types, which
I'd have to go read the full telnet source to understand.
I've CC'd Ted Ts'o on this message, in case he wants to make additional
comments about the nature of the original problem, or the other changes
made by that patch.
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
