BSD tty security, part 3: How to Fix It

Sun May 5 03:32:45 AEST 1991

In article <kre.673349595 at mundamutti.cs.mu.OZ.AU> kre at cs.mu.oz.au (Robert Elz) writes:
>ssd at engr.ucf.edu (Steven S. Dick) writes:
>
>>I've written my own write replacement [which I probably should release
>>to the net] that lets you type your whole message before it sends it.
>
(a bit deleted...)

>not supposed to sit and wait for the rest of the message after you see the
>line with the sender's name on it - you're supposed to write back, write

(This may be strictly off the alt.security path, but if "write" was made to 
behave as "msg" or "tm" - descrived below, these security might become
academic....)

Hmm, I dunno - seems you are letting the current form of "write" drive your
expectations of what "write" should be, rather that deciding what you want
then giving "write" that form (i.e. you are letting the technology drive 
your requriements rather than vice-versa).

How about an example from the (shudder) ibemm world (ibemm is the 
pronounciation of a well known and much dumped-upon TLA company name,
for those of you who don't know.....):  the "msg" and "tm" commands.

msg is a system command with syntax

msg USERNAME [AT HOSTNAME] [message text] RETURN

msg sends one line (up to ~120 character messages to the indicated recipient;
tm is an EXEC (i.e. a mainframe shell script) that packages msg messages in
a configurable border, with configurable line lengths, and prefixes the
FROM_USERID_AT_HOSTNAME info to each line.  If you want a multiline message,
you type a continuation character (also configurable) at the end of the line
of text you wish to continue.

When you hit the RETURN key in msh, or in tm without having specified a
continuatiuon character, the message is sent; and each line is prefixed 
with FROM_USERID_AT_HOSTNAME information.

There is NO WAY to flood someone's tty without them knowing who is doing
the flooding, as each line output to the tty is identified with the sender's
userid.  (examples below)

This allows you to "chat" interactively with one person (and a "chat" 
facility that sits on top of "msg" and allows a multi-party conversation
with private message capability exists as well) without them being able
to flood your tty, or otherwise boggle your mind without you knowing who 
is doing it.

The easiest way to fix some of the write-related security holes that have
been under discussion?  Implement msg, tm, and chat, and remove write.
(To avoid problem like the redirection one seen above, do not let "msg" 
read from stdin - though "tm" and "chat" could, seeing has how they will
exist on top of "msg".)  Further, restrict "msg" to sending non-CTRL
characters only.

What about programs that currently use write?  Well, they are generally
shell scripts, right?  It may be a headache to fix them all, but if the
write command was replaced by a script that notified the user to switch to
"msg", then it wouldn;t take long for people to fix things up, especially
if they were given advance warning of the changeover.

Perhaps eliminating write and implementing a better solution is a more 
appropriate way of fixing the problems with write?
(I am not volunteering for this.... :->).

Peter W.
pww at bnr.ca

(Examples of "msg" and "tm" below)

So, if I type "msg QQQ at bnr.ca Hi Q, how ya doin'? <RETURN>", QQQ at bnr.ca
sees (in bold, by the way)

MSG FROM QQQ at bnr.ca : Hi Q, how ya doin'?

If I use "tm", with its very tailorable output behavior, with "\" as my 
continuation character, the following results:

tm QQQ at bnr.ca Hi Q, ho ya doin'?  We are going to the \ <RETURN>
CONT:  beach this afternoon, wanna come?  MJ and SP \ <RETURN>
CONT:  will be there!!! <RETURN>

(CONT: is a bold/highlighted prompt from "tm")

QQQ at bnr.ca sees:

--
Peter Whittaker      [~~~~~~~~~~~~~~~~~~~~~~~~~~]   Open Systems Integration
pww at bnr.ca           [       DSA's'R'Us!        ]   Bell Northern Research 
Ph: +1 613 765 2064  [                          ]   P.O. Box 3511, Station C
FAX:+1 613 763 3283  [__________________________]   Ottawa, Ontario, K1Y 4H7