larrym@rigel.uucp (24121-E R Inghrim(3786)556) (08/22/89)
I am in the process of putting together a ".plan" file, and I've noticed that when I finger some users, they've got these plans with simple animated figures jumping and beeping. How can I make up a .plan file like those? -larry mcglynn
deke@ee.rochester.edu (Dikran Kassabian) (08/24/89)
In article <61@towernet.UUCP> larrym@rigel.uucp (24121-E R Inghrim(3786)556) writes: >I am in the process of putting together a >".plan" file, and I've noticed that when >I finger some users, they've got >these plans with simple animated figures jumping >and beeping. How can I make up a .plan file like those? Wow, what a bad idea. I may be jumping to conclusions here but it sounds to me like these users have terminal-dependant cursor addressing and the like in their .plan file. This is dandy if you happen to have the right terminal, but lousy if you don't. There's the potential of messing up your terminal settings by having your terminal misinterpret the intended meaning of that stuff. While there certainly are some tools that know how to reference terminfo or termcap in order to perform this stuff on any terminal with a correct entry, there are no versions of the finger/fingerd that do this that I know of. If you REALLY know for sure that EVERY person that will finger you will be using (for example) a vt100, you could construct some neat but simple animation by making a file that contains the appropriate cursor addressing and characters, including space characters (' ') where needed to erase. ^Deke Kassabian, deke@ee.rochester.edu or ur-valhalla!deke Univ of Rochester, Dept of EE, Rochester, NY 14627 (+1 716-275-3106)
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/25/89)
In article <1989Aug23.192105.21328@ee.rochester.edu> deke@ee.rochester.edu (Dikran Kassabian) writes: >In article <61@towernet.UUCP> larrym@rigel.uucp (24121-E R Inghrim(3786)556) writes: >>when I finger some users, they've got these plans with simple animated >>figures jumping and beeping. >these users have terminal-dependant cursor addressing and the like in >their .plan file. If "finger" really does dump the contents of .plan literally to a terminal, then you could exploit that misfeature to force-feed one of the terminal's programmable function keys, then dump it back. That's a good way to run commands under somebody else's UID! This would be a security hole that needs to be fixed.
hartzell@boulder.Colorado.EDU (George Hartzell) (08/25/89)
In article <10814@smoke.BRL.MIL>, gwyn@smoke (Doug Gwyn) writes: >In article <1989Aug23.192105.21328@ee.rochester.edu> deke@ee.rochester.edu (Dikran Kassabian) writes: >>In article <61@towernet.UUCP> larrym@rigel.uucp (24121-E R Inghrim(3786)556) writes: >>>when I finger some users, they've got these plans with simple animated >>>figures jumping and beeping. >>these users have terminal-dependant cursor addressing and the like in >>their .plan file. > >If "finger" really does dump the contents of .plan literally to a terminal, >then you could exploit that misfeature to force-feed one of the terminal's >programmable function keys, then dump it back. That's a good way to run >commands under somebody else's UID! This would be a security hole that >needs to be fixed. A program called dotplan was posted a while back that used combinations of backspaces and carriage returns to draw simple animations. I've used this in my dotplan in the past. I can understand how you one could program the functions keys, but how could you simulate one being pressed? g. George Hartzell (303) 492-4535 MCD Biology, University of Colorado-Boulder, Boulder, CO 80309 hartzell@Boulder.Colorado.EDU ..!{ncar,nbires}!boulder!hartzell
fuat@cunixc.cc.columbia.edu (Fuat C. Baran) (08/25/89)
In article <10814@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >If "finger" really does dump the contents of .plan literally to a terminal, >then you could exploit that misfeature to force-feed one of the terminal's >programmable function keys, then dump it back. That's a good way to run >commands under somebody else's UID! This would be a security hole that >needs to be fixed. It's not really finger that needs to be fixed, but the terminal. There should be a way to lock out reprogramming of function keys, etc. in a setup menu. People using such terminals should be aware of the risks. Otherwise, all you need to do is put a file called /tmp/PLEASE-README, and wait for someone with the right terminal (and capabilities) to cat it. And that isn't a security hole in cat... --Fuat -- INTERNET: fuat@columbia.edu U.S. MAIL: Columbia University BITNET: fuat@cunixc.cc.columbia.edu Center for Computing Activities USENET: ...!rutgers!columbia!cunixc!fuat 712 Watson Labs, 612 W115th St. PHONE: (212) 854-5128 New York, NY 10025
ag@cbmvax.UUCP (Keith Gabryelski) (08/25/89)
In article <11023@boulder.Colorado.EDU> hartzell@boulder.Colorado.EDU (George Hartzell) writes: >I can understand how you one could program the functions keys, but how >could you simulate one being pressed? I can easily see a person who uses fuction keys being duped into sending some unknown command to the host machine/ Programming function keys is not the only problem. Some terminals have the ability to write their current line (or page) to the terminal. This could be used to send anything to the host machine as if the user typed it from the keyboard. Pax, Keith -- "It took no computation to dance to the rock 'n roll station" -- VU ag@cbmvax.commodore.com Keith M. Gabryelski ...!uunet!cbmvax!ag
barmar@think.COM (Barry Margolin) (08/26/89)
In article <1810@cunixc.cc.columbia.edu> fuat@cunixc.cc.columbia.edu (Fuat C. Baran) writes: >It's not really finger that needs to be fixed, but the terminal. I think it's Unix that needs to be fixed. Multics's (and some other systems') solution to this problem is that the tty driver normally translates most control characters to octal escapes or ^<char> sequences. Applications that need to send control sequences to the terminal can put the terminal in raw output mode, but by default terminals are not in raw output mode. Programmable function keys are useful for some things, so telling the users to turn off this feature when using Unix is the wrong answer. With this "solution", every time a user goes into or out of an application that makes use of function key programming he'd have to change the set-up configuration. For novice computer users, this could be quite confusiong. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
fuat@cunixc.cc.columbia.edu (Fuat C. Baran) (08/26/89)
In article <28110@news.Think.COM> barmar@think.com (Barry Margolin) writes: >I think it's Unix that needs to be fixed. Multics's (and some other >systems') solution to this problem is that the tty driver normally >translates most control characters to octal escapes or ^<char> >sequences. Applications that need to send control sequences to the >terminal can put the terminal in raw output mode, but by default >terminals are not in raw output mode. 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? Regardless of what the default action of the terminal driver is, if a program can change it and send junk to an unsuspecting user's terminal, then the user is in danger. >Programmable function keys are useful for some things, so telling the >users to turn off this feature when using Unix is the wrong answer. >With this "solution", every time a user goes into or out of an >application that makes use of function key programming he'd have to >change the set-up configuration. For novice computer users, this >could be quite confusiong. Just out of curiosity, what unix applications make use of a terminal's capability to rebind function keys and/or have it type back arbitrary data on command? (No, this is not a sarcastic comment, but a genuine question. I don't think I've ever run across an application that required that capability from my terminal other than silly programs written as jokes by friends.) --Fuat -- INTERNET: fuat@columbia.edu U.S. MAIL: Columbia University BITNET: fuat@cunixc.cc.columbia.edu Center for Computing Activities USENET: ...!rutgers!columbia!cunixc!fuat 712 Watson Labs, 612 W115th St. PHONE: (212) 854-5128 New York, NY 10025
cpcahil@virtech.UUCP (Conor P. Cahill) (08/26/89)
In article <1815@cunixc.cc.columbia.edu>, fuat@cunixc.cc.columbia.edu (Fuat C. Baran) writes: > In article <28110@news.Think.COM> barmar@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. ANY USER THAT RUNS A PROGRAM IN ANY DIRECTORY WHEN THE USER DOES NOT KNOW WHAT THE PROGRAM IS (OR IS SUPPOSED TO DO) OPENS A VERRRRRRRRRRY LARGE SECURITY HOLE. > Just out of curiosity, what unix applications make use of a terminal's > capability to rebind function keys and/or have it type back arbitrary > data on command? (No, this is not a sarcastic comment, but a genuine > question. I don't think I've ever run across an application that > required that capability from my terminal other than silly programs > written as jokes by friends.) We routinely rebind the function keys at login time so that each user can have thier own set of meanings for the keys. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
jdpeek@RODAN.ACS.SYR.EDU ("Jerry Peek") (08/27/89)
In article <28110@news.Think.COM> barmar@think.com (Barry Margolin) writes: > In article <1810@cunixc.cc.columbia.edu> fuat@cunixc.cc.columbia.edu (Fuat C. Baran) writes: > >It's not really finger that needs to be fixed, but the terminal. > > I think it's Unix that needs to be fixed. About the animation from the '.plan' files... When I worked at one company and we converted to 4.3BSD, all the cute animation in the '.plan' files stopped screwing up peoples' screens. It turned out that 'finger' had been fixed to filter out non-text characters. I think they did the same thing to commands like 'write' and 'talk', too. I don't know who fixed 'finger': Berzerkley or our company's hackers. It was a great idea [though I missed the .plan file that flashed a lightning bolt across the screen on Tek 41xx terminals... I got over it :-)]. --Jerry Peek; Syracuse University Academic Computing Services; Syracuse, NY jdpeek@rodan.acs.syr.edu///JDPEEK@SUVM.BITNET///GEnie: J.PEEK1 +1 315 443-3995
guy@auspex.auspex.com (Guy Harris) (08/27/89)
>I don't know who fixed 'finger': Berzerkley or our company's hackers.
It was Berkeley - the 4.3 "finger" filters out non-printables in
".project" and ".plan" files, and also filters them out of the output of
a remote machine's "finger" service. That probably puts paid to the
guy's hopes of a cute animated ".plan" file, although given the
device-dependencies of same it's probably no great loss....jessea@dynasys.UUCP (Jesse W. Asher) (08/27/89)
In article <61@towernet.UUCP> larrym@rigel.uucp (24121-E R Inghrim(3786)556) writes: >I am in the process of putting together a >".plan" file, and I've noticed that when >I finger some users, they've got >these plans with simple animated figures jumping >and beeping. How can I make up a .plan file like those? > >-larry mcglynn Can someone be even more basic and explain what a ".plan" file is and what it's used for? Thanx....
forys@snake.utah.edu (Jeff Forys) (08/27/89)
In article <2387@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > > I don't know who fixed 'finger': Berzerkley or our company's hackers. > > It was Berkeley - the 4.3 "finger" filters out non-printables in > ".project" and ".plan" files [...] Well, not exactly. While 4.3BSD finger(1) made an attempt at filtering out non-printables, the actual code (thru Tahoe) doesnt quite work: if (isprint(c) || isspace(c)) putchar(c); else putchar(c ^ 100); That last line was obviously a mistake, and people with an abundance of free time will have little difficulty figuring out how to get escape and assorted meta characters to "come thru". The author of that particular line of code probably meant to do something like: putchar(0x7f & (c | 0100)); Fortunately, it appears that the finger program has undergone a complete rewrite, so future releases of BSD should not have this problem. --- Jeff Forys @ Unv of Utah/Salt Lake, Comp Sci Dept. (801-581-4280) forys@cs.utah.edu -or- ..!{boulder,decvax,nbires}!utah-cs!forys
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/28/89)
In article <11023@boulder.Colorado.EDU> hartzell@boulder.Colorado.EDU (George Hartzell) writes: >I can understand how you one could program the functions keys, but how >could you simulate one being pressed? Some terminals support an escape sequence that, when received, causes the contents of the specified function key to be transmitted just as though the key was pressed. Isn't that wonderful?
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/28/89)
In article <1810@cunixc.cc.columbia.edu> fuat@cunixc.cc.columbia.edu (Fuat C. Baran) writes: >It's not really finger that needs to be fixed, but the terminal. Well, that's not generally an option. >/tmp/PLEASE-README, and wait for someone with the right terminal (and >capabilities) to cat it. And that isn't a security hole in cat... Anoyone who uses "cat" to display unknown file contents on his fancy terminal deserves whatever he gets. However, in the case of "finger", there is no alternate method available (assuming remote system use). Therefore "finger" ought to better support its intended use.
bbadger@x102c.harris-atd.com (Badger BA 64810) (08/28/89)
In article <1077@virtech.UUCP> cpcahil@virtech.UUCP (Conor P. Cahill) writes: %In article <1815@cunixc.cc.columbia.edu>, fuat@cunixc.cc.columbia.edu (Fuat C. Baran) writes: %> In article <28110@news.Think.COM> barmar@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@trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.
ado@elsie.UUCP (Arthur David Olson) (08/29/89)
> Use only trusted applications which filter out the nasty sequences.
Don't "ls /tmp" since an evil user might give a file an evil name?
--
Gettysburg Address: 266 words. Spencer article bodies, 8/12-18/89: 14439 words.
Arthur David Olson ado@alw.nih.gov ADO is a trademark of Ampex.barnett@crdgw1.crd.ge.com (Bruce Barnett) (08/29/89)
In article <2620@trantor.harris-atd.com>, bbadger@x102c (Badger BA 64810) writes: >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. Also, don't allow anyone in the room with such a terminal. Most vt100's allow anyone to change the ANSWERBACK string if they can physically access the terminal. I also suggest that if you EVER use a vt100 that is in a public place, and you are concerned with security, you check what happens when a Control-E is sent to the terminal everytime you log into your account. -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
wyle@inf.ethz.ch (Mitchel Wyle) (08/29/89)
Plan: Segmentation fault (core dumped). ...scares the hell out of some people ;-)
guy@auspex.auspex.com (Guy Harris) (08/30/89)
>> Use only trusted applications which filter out the nasty sequences. > >Don't "ls /tmp" since an evil user might give a file an evil name? Or either 1) use only the BSD "ls" or 2) if you have a sufficiently modern version of S5, use "ls" only with the "-q" or "-b" options, so that non-printable characters are displayed as "?" or as "\nnn". Of course, this doesn't cover all the programs that can be coaxed into printing out evil file names....
al@escom.com (Al Donaldson) (08/30/89)
In article <2620@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. For example, a couple of years ago one of my co-workers
read the manual for his terminal (a Freedom 100, I think) and found that
if you echoed a magic escape sequence to the terminal followed by some
command string, the terminal would automatically send the command string
back on the line just as if the user sitting at the terminal had typed it in.
I don't remember the exact terminal or magic sequence, but I do remember
that it opened my eyes to a whole set of risks that I hadn't imagined before.
I think this is the same general problem that Doug Gwyn was talking about
<10847@smoke.BRL.MIL> when he answered a question about remotely simulating
the pressing of a function key. But in this case no function keys were used.
The only solution I know to this problem, short of using terminals that
don't have such awful holes (unfortunately, the terminal designer and
most users probably see this as a "feature" instead of a hole) is to disable
messages from other users to your terminal (e.g., "mesg n").
However, I am a little confused by the discussion about ANSWERBACK sequences
by BA Badger (above reference) and Bruce Barnett <1966@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 Donaldsonrobert@jive.sybase.com (Robert Garvey) (08/31/89)
In article <474@escom.com> al@escom.com (Al Donaldson) writes: >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. Yes, that is the risk. Some terminals allow answerback messages to be programmed with an escape sequence. A malicious user could send mail that includes that escape sequence with an answerback message to be interpreted by mail and then your shell. Following that sequence would be a ctrl-E. Robert Garvey Sybase, Inc robert@sybase.com 6475 Christie Ave {sun,lll-tis,pyramid,pacbell}!sybase!robert Emeryville, CA 94608
barmar@think.COM (Barry Margolin) (08/31/89)
In article <474@escom.com> al@escom.com (Al Donaldson) writes: >The only solution I know to this problem, short of using terminals that >don't have such awful holes (unfortunately, the terminal designer and >most users probably see this as a "feature" instead of a hole) is to disable >messages from other users to your terminal (e.g., "mesg n"). How would "mesg n" solve the problem with plan files containing these control sequences (see the Subject line of your message)? The only general solution is to fix the OS so it doesn't send control sequences except when the application really wants them. >However, I am a little confused by the discussion about ANSWERBACK sequences >by BA Badger (above reference) and Bruce Barnett <1966@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. Answerbacks are also used by some systems to determine the type of terminal. Honeywell VIP terminals send an answerback that begins with the model number, and many other terminals send unique answerbacks. Multics sends an ENQ (ctl-E) to a terminal when it dials up to try to automatically set the terminal type. I think I've heard of Unix utilities that try to do the same thing. > 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. What difference does it make whether Unix normally uses answerbacks. The point is that many terminals have settable answerbacks, and they can be triggered to send them. If you print out a file that contains the answerback-setting control sequence followed by an ENQ, the answerback will be transmitted as if you had typed it. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
bbadger@x102c.harris-atd.com (Badger BA 64810) (09/01/89)
In article <474@escom.com> al@escom.com (Al Donaldson) writes: >In article <2620@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@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@trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/01/89)
In article <474@escom.com> al@escom.com (Al Donaldson) writes: >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? Yes -- it's yet another place for eventual faked input to be stored in the terminal. So far we have: - Answerback (triggered by ^E) - Programmable function key (triggerable on some terminals) - Display memory (triggerable on some terminals) There may be others. The one thing they all have in common is that the trigger must be sent to them, which under normal circumstances wouldn't occur. Only if somebody has found a way to get arbitrary characters sent to user terminals does the potential problem become a real one. There are a number of Trojan horse and other approaches that could be used to send a trigger; the reported "finger" behavior was one of the easiest ones.
cpcahil@virtech.UUCP (Conor P. Cahill) (09/01/89)
Answerbacks are only part of the problem. I have worked with terminals that have enough local smarts to handle sequences from the system that ask for a dump of certain areas of the terminal. So you could write data to the terminal so that it is displayed on the screen and then send the sequence to the terminal that asks the terminal to dump that area of the screen. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
mbt@bridge2.ESD.3Com.COM (Brad Turner) (09/01/89)
In article <28607@news.Think.COM> barmar@think.COM (Barry Margolin) writes: >In article <474@escom.com> al@escom.com (Al Donaldson) writes: >.......[stuff deleted]........... The only >general solution is to fix the OS so it doesn't send control sequences >except when the application really wants them. Well the only problem is that "finger" is an application and it really does want to send whatever is in the .plan file to your tty. Given the open nature of UNIX might it be better for the system adminstrator to put finger in a shell script which pipes it's output to strings? Just an idea... -brad- P.S. I know this is treating the symptom and not fixing the problem. -- v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v Brad Turner |2081 Shoreline Blvd.|(415) 969-2099 ext 217 | I speak for myself 3Com Corp. |Mtn. View, CA 94043 |mbt@bridge2.ESD.3Com.Com| NOT for my employer
bbadger@x102c.harris-atd.com (Badger BA 64810) (09/02/89)
The termincal characteristics which lead to the security faults have been
recognized and given standards designations in terminfo and termcap:
From HCX/UX man terminfo:
pkey_key pfkey pk Prog funct key #1 to type string #2
pkey_local pfloc pl Prog funct key #1 to execute string #2
pkey_xmit pfx px Prog funct key #1 to xmit string #2
plab_norm pln pn Prog label #1 to show string #2
From Sun man termcap:
pk str program function key n to type string s (terminfo only)
pl str program function key n to execute string s (terminfo only)
pn str (NP) program label n to show string s (terminfo only)
px str program function key n to transmit string s (terminfo only)
What next, terminal-independent nasty-grams? Maybe a terminal capability
for forge_output and wreak_havoc should be standardized? (:-o) Oh Nooo!
----- - - - - - - - ----
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@trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.bph@buengc.BU.EDU (Blair P. Houghton) (09/02/89)
Any objections to using (in csh): alias finger '/usr/bin/finger \!* | cat -v' to eliminate the non-printingness of ^E and the like? --Blair "Or am I missing something?"
barmar@think.COM (Barry Margolin) (09/04/89)
In article <4011@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: >Any objections to using (in csh): > alias finger '/usr/bin/finger \!* | cat -v' >to eliminate the non-printingness of ^E and the like? > "Or am I missing something?" OK, what about reading mail? Or printing random files with "cat"? My point is that there are a large number of programs that print files you didn't create to your terminal. Any such program that doesn't filter its output can be used to transmit a trojan horse. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
cmf@obie.cis.pitt.edu (Carl M. Fongheiser) (09/05/89)
In article <9136@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: >> Use only trusted applications which filter out the nasty sequences. > >Don't "ls /tmp" since an evil user might give a file an evil name? That's right! Everybody knows the only safe way to "ls" /tmp is to pipe it through "cat -v" :-) Carl Fongheiser cmf@unix.cis.pitt.edu
bob@wyse.wyse.com (Bob McGowen Wyse Technology Training) (09/07/89)
In article <1077@virtech.UUCP> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >In article <1815@cunixc.cc.columbia.edu>, fuat@cunixc.cc.columbia.edu (Fuat C. Baran) writes: >> In article <28110@news.Think.COM> barmar@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 ---deleted--- >ANY USER THAT RUNS A PROGRAM IN ANY DIRECTORY WHEN THE USER DOES NOT KNOW WHAT >THE PROGRAM IS (OR IS SUPPOSED TO DO) OPENS A VERRRRRRRRRRY LARGE SECURITY HOLE. > >> Just out of curiosity, what unix applications make use of a terminal's >> capability to rebind function keys and/or have it type back arbitrary ---deleted--- >We routinely rebind the function keys at login time so that each user can >have thier own set of meanings for the keys. > ---deleted--- Binding a function key may not require the user(owner)'s ID or permissions. When a user logs in the device they are on is set to rw--w--w-, which allows others to write (using the command of the same name) to other users. If the proper sequences can be sent to this device and the terminal will accept them, then when the user on the terminal tries the function key the result will be sent to the system and run with that users ID. The ways to stop this include: 1) having the driver convert control characters to printing ascii unless in raw mode (which hopefully can only be done by the owner of the tty); 2) setting the permissions on the tty to rw-------, using mesg n. 3) use a terminal that has no function keys or that cannot be programmed from the computer side. Otherwise, caveat emptor! Bob McGowan (standard disclaimer, these are my own ...) Customer Education, Wyse Technology, San Jose, CA ..!uunet!wyse!bob bob@wyse.com