Xref: utzoo comp.unix.wizards:13170 comp.protocols.misc:408
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cs.utexas.edu!rutgers!noao!amethyst!rsm
From: rsm@amethyst.ma.arizona.edu (Robert Maier)
Newsgroups: comp.unix.wizards,comp.protocols.misc
Subject: flaw in RLOGIN protocol?
Message-ID: <858@amethyst.ma.arizona.edu>
Date: 4 Dec 88 11:48:58 GMT
Sender: news@amethyst.ma.arizona.edu
Organization: Dept. of Math., Univ. of Arizona; Tucson, AZ  85721
Lines: 26

I recently dug into the BSD4.3 versions of rlogin.c and rlogind.c, and
among other things figured out the (undocumented?) RLOGIN protocol.

Once the TCP/IP connection between server and client has been
initialized, it is only used to transfer data.  The control path from
server to client is out-of-band, and supports little more than an
output flush request.

There is one exception to this: the rlogin client may place in the
data stream going to the server a notification that its screen size
has changed.  The client uses the escape sequence "\0377\0377ss",
followed by the new screen size.

So far as I can see, this escape sequence cannot be escaped.  There is
no way of passing "\0377\0377ss" from the client to the server without
the following bytes being interpreted as a new screen size.

Am I missing something here, or does this imply that the RLOGIN
protocol doesn't support a true 8-bit data path?

--
Robert S. Maier
SNAIL: Dept. of Math.; Univ. of Arizona; Tucson, AZ 85721; USA
VOICE: +1 602 621 6893 / +1 602 621 2617
UUCP: ..{allegra,cmcl2,hao!noao}!arizona!amethyst!rsm
BITNET: maier@arizrvax          INTERNET: rsm@amethyst.ma.arizona.edu