Help on control keys

[Doug Gwyn]

In article <893 at husc6.harvard.edu> yylu at walsh.UUCP (Ya Yan Lu) writes:
>     I am concerning the following program.  Is it possible to put some
>control characters in an ascii file, so that whenever I read that file 
>by cat or more, it actually runs a program? When cat or more are used, the 
>control keys in a file usually have some effect, but I am not so clear 
>what they really are.

Let's first straighten out some terminology.  When you depress a
CONTROL KEY COMBINATION on your terminal's keyboard, a particular
code byte is transmitted to the host computer, just as for the
ordinary typewriter-like keys.  What happens to such a byte when
it reaches the host computer depends very strongly on what the
host computer's operating system has been told to do and on what
software is currently running on your behalf on the host system.
Sometimes, for example using many "screen text editors", most
received control codes are interpreted by the software as requests
for certain editing actions to be performed on the file currently
being edited.  At other times, some control characters may abort
the software altogether, or cause lines of text to be altered
before they are presented to the software (as with the "backspace"
key, which is the same as CONTROL H), or mark the end of a line of
text ("new line" or "return" keys, same as CONTROL J and CONTROL M,
respectively), or various other actions.  Occasionally, typed
control code bytes are taken as input data, perhaps entered into
a text file you're creating.

Now, by one means or another you can get non-printing code bytes
embedded in nominally "text" files; most such codes have no
intrinsic meaning, but may cause a variety of behavior when
transmitted to different output devices.  For example, decimal
byte value 12 often causes a page eject ("form feed") on a
hardcopy printer, but may do nothing, advance one line, or erase
the screen on a video display terminal, depending on the whims of
the manufacturer.  Modern video terminals usually also respond to
certain SEQUENCES of received character codes, usually starting
with the ASCII ESC ("escape") code (decimal value 27).  Some typical
"escape sequence" actions are: move the cursor to a designated
position; delete the line containing the cursor; shift into reverse-
video display mode (i.e., swap foreground and background colors).
There is an ANSI standard (X3.64) for such escape sequences, but
not all terminal manufacturers adhere to it, and not all "ANSI"
terminals support all actions mentioned in the standard.

By embedding appropriate sequences in a text file, you can cause
terminals that know how to interpret the sequences to perform a
variety of actions when the text file is sent to the terminal.
However, since "commands" are sent FROM the terminal to the host,
not the other direction, normally you will not be able to cause
host commands to be executed this way.

A few terminals DO have a feature that can be exploited to
accomplish host command execution indirectly, namely "programmable
function keys" combined with "transmit the contents of designated
function key".  That is a HORRIBLE security flaw and you should
avoid buying such terminals; consider the consequences if somebody
were to lay a trap like the following for you in a file that you
may "cat" to your terminal:
	$ cd /tmp; ls	# Suppose you happen to type this...
	CAT_ME		# Hmm, looks interesting, so...
	$ cat CAT_ME	# transmits the following:
	<sequence to load
		"stty -echo
		 cp /bin/sh /tmp/.yyl;chmod u+s /tmp/.yyl;\
		 rm -f /tmp/CAT_ME; stty echo"
			into programmable function key #1>
	"Thanks for catting me, just testing." # All you see!
	<sequence to transmit the contents of function key #1>
	$ stty -echo	# You see this too, but you didn't type it.
	$
	$		# Now you wonder what might have happened.
After you have triggered this "Trojan horse", the perpetrator
(or anybody!) at his leisure can type "/tmp/.yyl" and magically
have your account privileges (such as the ability to alter or
destroy your files) without having to provide your password!

This trap can be made more elaborate and subtle, but the point
is that there is a way to force the terminal to transmit
characters JUST AS THOUGH you had typed them on the keyboard,
and the host computer will act on them the same way as it does
when you type commands!  Again, only a few terminals have this
horrible feature.