.plan

[Badger BA 64810]

In article <1077 at virtech.UUCP> cpcahil at virtech.UUCP (Conor P. Cahill) writes:
%In article <1815 at cunixc.cc.columbia.edu>, fuat at cunixc.cc.columbia.edu (Fuat C. Baran) writes:
%> In article <28110 at news.Think.COM> barmar at think.com (Barry Margolin) writes:
%> 
%> I still think that the ability to send back arbitrary strings is too
%> dangerous to be enabled by default in terminals.  User's should be
%> aware of it when they enable that capability.  What's to prevent a
%> nasty user from creating a /tmp/RUN-ME program that puts the tty in
%> raw output mode and then does bad things?
%
%If you can get somebody to run the program RUN-ME, they you don't have to 
%do anything to the terminal because you are already running a program with
%the full capabilities (permissions) of the user.  At this point you wouldn't
%have to bind F10 to "rm -rf ." because you could just run "system("rm -rf .")"
%or do something like chown(program_in_your_directory,getuid()),
%chmod(program_in_your_directory,04777)  which would then allow you to become
%that user whenever you want.

Such a terminal is vulnerable to any raw string which can be made to
go to the terminal.  There are (at least) three different ways to get 
the nasty strings sent to the terminal.

The first is to write a program which puts out the nasty strings, and 
get the victim to run the program.  This is the classic ``Trojan
Horse'' attack, which as you point out already has the potential to 
do damage directly, and does not need to use the terminal echo capabilities.

The second approach is for the attacker to simply redirect the output
of some program to the victim's terminal:
	% echo '<def F1>^Zrm -rf ~ &\nfg \n<end><echokey F1>' > /dev/ttyNN
Where the sequences enclosed in '<' and '>' are terminal-specific
codes with the given meanings.  Note that this is also essentially
what the UNIX write (1) command does.
	% write $VICTIM $NASTY_GRAM
The DEC VT series and their many emulators have this problem.  The

The third approach is to get the user to copy your data string to his
display using a program already trusted by the user.  This is how the 
``.plan'' bug would work.  The user already trusts the finger program,
and it does not have to be modified.  It also does not have to
overcome a ``mesg n'' command, which will foil method #2.  Examples of
this problem abound:  finger, mail.

A special problem with these terminals is that programs which assume that
a ``trusted path'' exists when using a terminal directly, can be
spoofed by input from another program.  For example, you normally cannot
run /bin/passwd from a pipe, since it insists on a terminal device.  

One thing which is almost funny, if it weren't so sad, is the WYSE-85 
ANSWERBACK feature.  It seems that by pressing the [REMOVE] key you
can cause the string "<CONCEALED>" to be displayed instead of the actual
answerback string.  Unfortunately, when an ENQ (^E) is received, the 
string is *sent* as the answerback to the computer!  The answerback
can also be manually triggered by SHIFT-CTRL-break (F5 key).  In
either case, the anserback string is exposed.

What can be done about this problem?  Don't use these terminals if you 
can avoid it, and if security is any importance to you.  Don't 
allow anyone to write directly to your terminal (mesg n).  Use only 
trusted applications which filter out the nasty sequences.  

You could install terminal drivers which recognize the terminal type, 
and filter out the nastygrams.  Many sites use only one or two types
of terminals, and this approach could probably be effective.  
Bernard A. Badger Jr.	407/984-6385          |``Use the Source, Luke!''
Secure Computer Products                      |``Get a LIFE!''  -- J.H. Conway
Harris GISD, Melbourne, FL  32902             |Buddy, can you paradigm?
Internet: bbadger%x102c at trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.