.plan

[Badger BA 64810]

In article <474 at escom.com> al at escom.com (Al Donaldson) writes:
>In article <2620 at trantor.harris-atd.com>, BA Badger points out that a
>(programmable) terminal is vulnerable to any raw string that can be sent 
>to the terminal. 
[...]
>However, I am a little confused by the discussion about ANSWERBACK sequences
>by BA Badger (above reference) and Bruce Barnett <1966 at crdgw1.crd.ge.com>.
>As I remember, answerback sequences were used years ago in multidrop line
>protocols to determine if a terminal was online and ready to receive before 
>sending a message.  Surely answerback is not used by UNIX for this purpose,
>so is the point that a nastygram can be stored in my terminal, triggered 
>remotely by echo'ing a ctrl-E to my terminal, with the nastygram getting 
>passed straight to my shell?   I apologize if this is obvious to others, 
>but I just want to be sure I understand the risk.
>
>Thanks,
>
>Al Donaldson
Yes, that's it!  Any ^E sent to a VT100 causes the ANSWERBACK string
to be sent from the terminal back down the line.  I don't know of any
way to *SET* the ANSWERBACK string remotely, though.  You have to go
to the terminal and use the SETUP key, and key it in manually.  That's 
what Bruce meant about being suspicious of any VT100 which is not
under your *continuous* control.  Even if you use a ``lock'' program
to prevent others from typing commands directly to your shell, you are
vulnerable to someone putting, say "^Zrm -rf ~&^Mfg^M", in the ANSWERBACK.
The next time your terminal gets a ^E, it's bye-bye files!  (Lot's of 
environmental assumtions here, of course.)  

``Just because you're paranoid, doesn't mean they're not out to get ya!''

Worse that that are the holes which allow a remote user to download things
to your terminal and then send it back.  The ``smarter'' your terminal
is, the more likely it is you should worry about this.  
Here's several ``smart'' things which could bite you:
	send answerback message
	send screen, line or character at cursor position
	report function key redefinition string
	get into ``loopback'' mode which echoes everything sent
	report some special data item (window attribute, font, context)
These are nasty because they can usually be set remotely to arbitrary strings.
If they are reported as raw ascii, then you are in trouble.

Some other ``reports'' are relatively harmless, because you have less control
over their contents or report format:
	report terminal type
	report cursor position
	report terminal mode
However, a ``lucky'' coincidence might mean that the cursor position
is returned as two ascii characters, (row,col).  Then you could
modulate that by sending cursor-positioning commands in between the
``report cursor'' position commands.
	
There are whole sections in my WY-85 (VT200 clone) ``Quick Reference Guide'' 
giving the control codes for:
	``Controlling Function Keys''
	``Sending Data''
	``Terminal Status Reports''

Even if your terminal can never send any response without someone physically
pressing a key, you are not safe!  If keys can be reprogrammed, then
the sequences sent will not be the ones intended by the person
pressing the key.

Well, *try* to play safe out there!


    -----	-	-	-	-	-	-	-	----
Bernard A. Badger Jr.	407/984-6385          |``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.