yylu@walsh.harvard.edu (Ya Yan Lu) (12/30/88)
Hi, netters,
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.
Thanks for any help.
=========================================================================
Ya Yan Lu
Department of Mathematics
Harvard University, MA 02138
yylu@zariski.harvard.edu
=========================================================================barmar@think.COM (Barry Margolin) (12/31/88)
In article <893@husc6.harvard.edu> yylu@walsh.UUCP (Ya Yan Lu) writes: > 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? In general, the answer is "No". Cat and more mostly just send the characters to the terminal (I think "more" will also recognize certain sequences as indicating underlining and inverse video, and translate them to the appropriate sequence for the terminal). Some terminals have mechanisms whereby a "answerback" strings may be programmed using control sequences, and then another control sequence causes it to send the answerback as if the user had typed it. For such terminals, the file could contain the sequence to program an answerback and then request it to be sent. If the answerback is set to be a command line, this mechanism could be used to cause a program to be run after the file is displayed. 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. Are you referring to the file that displays a train going around a christmas tree when you cat it? In that case, the file simply contains the control sequences that cause characters to be displayed and erased at the appropriate places on a VT100-compatible terminal. The control characters in the file aren't causing a special program to run, they're just being sent to the terminal, and you're seeing the results of those control sequences on the terminal's display. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/02/89)
In article <893@husc6.harvard.edu> yylu@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.
jiml@uwslh.UUCP (James E. Leinweber) (01/03/89)
In <9259@smoke.BRL.MIL> Doug Gwyn writes: > 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 ... There are a few of us out here that buy such terminals because we use them for "block mode" data entry, in which a screen full of information layed out in protected and editable fields is modified locally at the terminal and then transmitted as one big lump to the host computer. Don't try it using standard Unix character at at time line disciplines (BSD & pre- V.3), though. We manage to support over 30 users on a lowly Vax 11/750 this way. Doug is quite right about the ease of exploiting such features for a trojan horse attack. I know of at least one instance at the UW-Madison where such a terminal was used to forge some e-mail as part of a security project demonstration. Block mode terminals are more common in mainframe, non-Unix environments (such as IBM's MVS) where this sort of attack has been known for a long time (under names like "the terminal loopback bug"). At least under 4.3 BSD, tty devices aren't publicly writtable, so that the victim has to cooperate to be attacked, rather than merely being logged in, which sufficed under stock 4.2 systems. Me, I always use "cat -v" :-) Beware of letter bombs on "intelligent" terminals too; most existing mailers are quite naive about passing escape sequences through. -- Jim Leinweber jiml@uwslh.uucp jiml%uwslh.uucp@cs.wisc.edu ...!{rutgers, ucbvax ...}!uwvax!uwslh!jiml State Laboratory of Hygiene @ Univ. of Wisconsin - Madison; (608) 262-0736
heilpern@ibd.BRL.MIL (Mark A. Heilpern ) (01/03/89)
In article <893@husc6.harvard.edu> yylu@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. > Thanks for any help. Define program. If you are refering to a 'graphics' type of display, yes. It is not possible, however, to give a code that tells cat to execute the command rather than print it. {Unless you feel like rewriting /bin/cat. If you do, there is a genereic source of the 'normal' cat in comp.sources.} To create a graphics display that is catted, there are two basic options. Just like your old instructor from school, I will explain the hard one first. 1) a) get out the manual for your terminal and thoroughly study all Control codes and escape codes for graphics/movement. b) decide what you want to do and use 'cat >file' and start giving the codes to do what you want the screen to do. [You will not be able to give ^D, kill chars, etc., and the screen may start performing these results, so don't be discouraged if you can no longer see waht you are typeing. Just remember to use ^D on a line by itself to end input. c) cat the file and observe. Do Not Use More, as this will pause in unwanted areas. 2) [easy?] a) write a program using curses to perform your desired functions. b) run this program with redirected output: $ program > catfile c) cat catfile and the same display should be seen. -- |\/| | | | _ |< / \_(_(_)\_/ \______
abcscnuk@csuna.UUCP (Naoto Kimura) (01/06/89)
In <9259@smoke.BRL.MIL> Doug Gwyn writes: > 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 ... > ... While at UCLA, when some people would try to annoy me by redirecting /usr/games/worms or /usr/games/rain to my terminal. I would retaliate by using a text file designed for the terminal that they using. In the file were the control sequences to: 1) lock the keyboard 2) clear the screen 3) set the terminal to display control characters rather than display them 4) output the string "logout\n" 5) send the transmit line sequence Of course, I could've been cruel and did other things, like execute "rm -rf ~" Other things possible were to append "logout" to their ".cshrc" Or even more fun, put a "chmod u-rwx ~" in their ".login" At times I would put a "chmod o+r `tty`" on their terminal instead of login. Then I would do a "tail -x" on their terminal. Of course, I could've gotten cute and interactively simulate the login process... While I'm at discussing different malicious things that can be done, another one is the file containing the control character to protect the entire screen except for one character at the middle of the screen. Of course it can be made worse by causing the entire screen to be protected. //-n-\\ Naoto Kimura _____---=======---_____ (csun!csuna!abcscnuk) ====____\ /.. ..\ /____==== // ---\__O__/--- \\ Enterprise... Surrender or we'll \_\ /_/ send back your *&^$% tribbles !!
heilpern@ibd.BRL.MIL (Mark A. Heilpern ) (01/07/89)
In article <1494@csuna.UUCP> abcscnuk@csuna.UUCP (Naoto Kimura) writes: >While I'm at discussing different malicious things that can be done, The following opinions are my own, though I believe I speak for the majority of the net: 1) This newsgroup, as well as ALL others I know of, is NOT a forum for kids to discuss how they can screw over another user or a system. 2) Methods of prevention of malicious activities is very welcome, how much fun you had while getting revenge is not. 3) I suggest, if the annoyence you've experienced happens again, rather than retaliate, simply check the permissions of all of your files and directorys, change your password, review major dot files, and include the command "mesg n" at the top of your .login or .profile. Mesg n will prevent others from redirecting anything to your terminal, as well as prevent them from 'write'ing to you. Of cource, this will not stop root from performing the mentioned activities, but if that is a problem, find a new computer system to work on. Mark A. Heilpern heilpern@brl.mil -- |\/| | | | _ |< / \_(_(_)\_/ \______
abcscnuk@csuna.UUCP (News Manager) (01/10/89)
In article <239@ibd.BRL.MIL> heilpern@brl.arpa (Mark A. Heilpern (IBD) <heilpern>) writes: >... (portion of my previous posting to which he was responding to deleted) ... > >The following opinions are my own, though I believe I speak for the majority >of the net: > >1) This newsgroup, as well as ALL others I know of, is NOT a forum for > kids to discuss how they can screw over another user or a system. It seems that my intentions were misinterpreted. Perhaps it was my choice of words, or how I chose to give my examples of how they can be a problem. I apologize for this. I was intending my reply to show examples in which "features" of terminals could be taken advantage of, and how far someone could take advantage of these weakenesses. >2) Methods of prevention of malicious activities is very welcome, how much > fun you had while getting revenge is not. Unfortunately, I do not know of any ways to prevent such malicious activities except for turning off your messages, or not use terminals with such weaknesses. My poor writing skills has caused my intent in using "fun" to be misinterpreted. These activities were far from being any fun. Things aren't any fun if they are too easy to do. I have never done anything more serious to anybody than logging them out forcibly. The intent was to describe what someone who really does enjoy doing these things may feel. >3) I suggest, if the annoyance you've experienced happens again, rather > than retaliate, simply check the permissions of all of your files and > directories, change your password, review major dot files, and include > the command "mesg n" at the top of your .login or .profile. Mesg n will > prevent others from redirecting anything to your terminal, as well as > prevent them from 'write'ing to you. Of cource, this will not stop > root from performing the mentioned activities, but if that is a problem, > find a new computer system to work on. > > Mark A. Heilpern > heilpern@brl.mil I did have a "mesg n" in my .login for some time, but I wasn't able to get messages from anybody who REALLY wanted to talk to me. They had to resort to sending mail, which often had a tendency to get "stuck" (mail was being "censored" on the undergrad systems at UCLA to prevent people from sending source code to one another; Actually it was passed through a program that examined to check for anything that resembled pascal code). Also, none of my files were readable by anyone in the same group (to prevent plagerism). Unfortunately, the programming assignments were supposed to be submitted and graded on that system. To use one of the other systems to which I had access to, I would have either retype everything or, find some way to get around the mail censor. To make matters worse, but I had to go through WISCVM just to send files between machines both located at UCLA. The people that I retaliated against felt that they were being "cute," simply because they knew how to do annoying things (sending "worms" output to someone else's terminal). It was "cute" for maybe the first few times, but it ceased to be so when they would repeat their attacks every few minutes or send "worms" into the background while they went and did their work. Though it was most definitely wrong to do so, I retaliated in the manner described in my message (logging them out). After logging them out, I sent them a message "Don't you ever do that again!" It usually got the point across. Perhaps I got a bit carried away in describing things that people could do with these "weaknesses" in some terminals. I apologize for this: I was not thinking (clearly) when making the posting (I had been up for a long time). > Mark A. Heilpern > heilpern@brl.mil //-n-\\ Naoto Kimura _____---=======---_____ (csun!csuna!abcscnuk) ====____\ /.. ..\ /____==== // ---\__O__/--- \\ Enterprise... Surrender or we'll \_\ /_/ send back your *&^$% tribbles !!