piggott@bnl.UUCP (Christopher Piggott) (08/13/84)
Forgive me if this is already understood, but being able to read the terminal settings of another's terminal also means that you can set some of those definitions for them - including the famous 'stty 0' - and force another's terminal to do funny things to them.... Does anybody know of any way to protect themselves against this other than the 'mesg n' which disallows ANY writing to your device? (piggott@bnl for replies + comments)
muller@sdccsu3.UUCP (Keith Muller) (08/15/84)
You can easily protect users from stty 0 and other nasties (like people sending the output of worms to each other) by using group access control on the users tty port. 1) Create a group called something like "term" that no users in it. 2) Change login to set the mode of the tty to have GROUP write access and turn off OTHER access. Also have login set the group of the tty (while login is still running as root) to the group "term". (Make sure that login does not end up running in group "term" as that would defeat the fix). 3) Change mesg to turn on and off the GROUP write permission leaving OTHER permission off. 4) Change programs like finger, write, talkd, ... to understand that GROUP write permission means you can write to the user (instead of other). 5) Change write to be setgid to "term" (talk is already setuid root so does not have to be changed as talkd determines who can be written to). This has stopped abuse (we have a large student population on 9 unix machines) completely. Keith Muller UCSD Computer Center
mcferrin@inuxc.UUCP (P McFerrin) (08/15/84)
>From ihnp4!mgnetp!burl!clyde!watmath!utzoo!linus!philabs!sbcs!bnl!piggott Sun Aug 12 17:59:18 1984 >From: piggott@bnl.UUCP (Christopher Piggott) >Newsgroups: net.bugs,net.bugs.4bsd >Subject: stty bug + effects >Article-I.D.: bnl.571 >Posted: Sun Aug 12 17:59:18 1984 > > Forgive me if this is already understood, but being able to read the >terminal settings of another's terminal also means that you can set some >of those definitions for them - including the famous 'stty 0' - and force >another's terminal to do funny things to them.... > Does anybody know of any way to protect themselves against this other >than the 'mesg n' which disallows ANY writing to your device? > >(piggott@bnl for replies + comments) > > I wasn't going to be the first one to let the 'cat' out of the bag!! But now the rest of the world knows how to hang up another person, I would expect that more people are going to disallow writes to their terminal. By allowing write permissions to your tty device, one can definitely hang you up or do screwy things to your terminal (e.g. no echo or raw). I know of no other way to protect youself other than removing write permissions by others. If you use group ids on your system, you can permit writes by other persons in your group by assuming that your group members are friendly co-workers. Allowing write permissions to your terminal can be dangerous if your terminal is capable of block-mode transmissions that can be initiated from the host. A possible solution would to to rework the write(1) command that would use some other harmless bit in the mode of the tty device. There is however an impact on other commands (e.g. nroff).
brian@muddcs.UUCP (08/15/84)
> Forgive me if this is already understood, but being able to read the >terminal settings of another's terminal also means that you can set some >of those definitions for them - including the famous 'stty 0' - and force >another's terminal to do funny things to them.... > Does anybody know of any way to protect themselves against this other >than the 'mesg n' which disallows ANY writing to your device? > >(piggott@bnl for replies + comments) Actually, you can do far worse than that to someone else's terminal. Under 4.2bsd at least, you can send a command line to someone else's terminal and have it executed as it that person typed it themselves. (Using a short 'C' program to do a ioctl TIOCSTI call). Also, people can send out control strings to terminals to put them into funny modes (on dec vt100's and vt200's you can put someone in inverse video, etc.) We saw this as a security problem so I elected to do the following fix. login, talk, write, and mesg were all changed so that a terminal is *ALWAYS* protected so that only it's owner has rw protections. Write now runs setuid to root (the shell escape doesn't have root privleges, I thought of that), the talkd already ran setuid; thus these programs can still access the other users terminal. I use the world "x" protection bit as a flag for whether or not a user doesn't want to be bothered. Talk and write use that as their criteria, and mesg now changes that bit rather than the actual terminal rw protections. This prevents other users from writing directly to terminals, they must use talk or write if they want to bother someone. We've been running it a couple of weeks now with no problems. I don't see any security holes in it, let me know if anyone out there sees any. If you don't want to waste the time looking for where to make all of these changes (and I wouldn't if I were you), send me mail and I'll send you the diff's on the files I changed. Oh, I also changed finger to accurately say whether or not a user had messages off under the new criteria. If I get enough requests for this, I'll post the diffs to the net. -brian -- Brian Zill 621-8000 x3497 Harvey Mudd College {ihnp4,allegra,seismo}!scgvaxd!muddcs!brian
dan@idis.UUCP (08/18/84)
Should the privilege to stty() depend on READ access instead of WRITE access?
john@genrad.UUCP (John Nelson) (08/20/84)
One short correction. On 4.1 and 4.2 you CANNOT force data on someone else's tty line via the TIOCSTI call. I am not sure how this is checked for (possibly both read and write permission are required on the descriptor), but I tried it, and it does not work!
guy@rlgvax.UUCP (Guy Harris) (08/21/84)
> One short correction. On 4.1 and 4.2 you CANNOT force data on > someone else's tty line via the TIOCSTI call. I am not sure > how this is checked for (possibly both read and write permission > are required on the descriptor), but I tried it, and it does > not work! TIOCSTI is only allowed 1) if the terminal in question is the control terminal of the process trying to do the TIOCSTI (to be technical, it's if the u.u_ttyp in the process' U page is the tty structure pointer for that terminal; u.u_ttyp gets set to the ttyp for the first terminal that the process opens if the process is not in any process group and the terminal doesn't belong to any process group) or 2) if you're the super-user. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
wjb@ariel.UUCP (08/22/84)
It has been a while since I looked at it but in 2.8 BSD (PDP-11s) I believe that the kernel checked your UID on attempting a TIOCSTI and only allowed root this privelege. Probably a good idea...
piggott@bnl.UUCP (Christopher Piggott) (08/24/84)
[Hey Bug!!! You got relatives???] Here is the way that I keep myself protected from the "stty 0 > /dev/ttyxx"'s of this world.... First, an automatic "mesg n" in my .profile. If somebody wants to page me for "talk", "write", or whatever, then tough. They'll send it through MAIL first if it's important enough. Second, if I wish to 'talk' with someone, I don't just use regular 'talk' or 'write'. I use this simple shell script, named "xtalk", in my directory. (sleep 20;mesg n;echo -n "*")& mesg y talk $1 And that takes care of things.... Now for a question....Is there any way I can read the response (someone writing to my terminal) from the SHell, without using the wait-loop type delay? Christopher Piggott (Piggott@BNL)
ron@wjvax.UUCP (Ron Christian) (08/28/84)
() *** >From: piggott@bnl.UUCP (Christopher Piggott): >Here is the way that I keep myself protected from the "stty 0 > /dev/ttyxx"'s >of this world.... >First, an automatic "mesg n" in my .profile. If somebody wants to page me >for "talk", "write", or whatever, then tough. They'll send it through >MAIL first if it's important enough. ******* Well, this seems paranoid to me. As well as having an important hole if you use a VT100. That is, a competant Terminal Warrior can get around a 'mesg n' with a little fiddling. Mail, also, is not really a valid replacement for talk or write unless you have 'biff' set, which is leaving yourself open again. I wonder if you miss phone calls if you're on a remote terminal. ******* >Second, if I wish to 'talk' with someone, I don't just use regular 'talk' >or 'write'. I use this simple shell script, named "xtalk", in my directory. >(sleep 20;mesg n;echo -n "*")& >mesg y >talk $1 >And that takes care of things.... *** Unless the person you want to talk to also has 'mesg n' set. What do you do then? The basic premise seems to be that you are the only one that needs protection, not your co-workers. Awhile ago, when terminal wars hits were flying hither and yon, everyone had 'mesg n' in his/her .login. As I mentioned, there are ways to circumnavigate this with preparation. So the only effect was that no one could contact any one else for legitimate means. Foolish. We tried some things, like a 'talk' that auto- matically hammered open the person's tty, but someone thought this might 'leave him open' so ran a script in the background that checked message bit and took appropriate action... Did you know that you can send those funny escape sequences through 4.1 'talk' if you type them in verbatum? There was also a race by a couple of people to aquire the su password (password stealing programs, or careful attention to unattended terminals) in order to break through someone else's protection. Real damage was done in the process. Anyway, the load average was climbing, and things were rapidly getting out of hand, so a message was handed down from above: "Cut this f***** crap out or lose your password." And THAT is the ONLY way you are going to stop this stuff. For every protection scheme there are a dozen ways to crack it. And individual protection schemes only provide a challange to folks who go in for this sort of thing. -- "Trivia is important." Ron Christian Watkins-Johnson Co. San Jose, Calif. (...ios!wjvax!ron)
barmar@mit-eddie.UUCP (Barry Margolin) (08/29/84)
There are a number of ways to allow users to send messages to each other
WITHOUT requiring that everyone have write access to /dev/tty*. One
that comes to my mind is to make write(1) and friends be setgid to
"write" and "chgrp write /dev/tty*". This also permits us to prevent
the security hole that "write" currently provides with programmable
terminals, since write(1) could be taught to censor escape sequences.
--
Barry Margolin
ARPA: barmar@MIT-Multics
UUCP: ..!genrad!mit-eddie!barmarwoods@hao.UUCP (Greg "Bucket" Woods) (08/30/84)
Better yet, write(1) could send control characters the same way the tty
driver echoes them back, i.e. instead of sending the literal character
\032 for ESC (or whatever the damn code is), it could send "^[". Similarly
for other control characters. This wouldn't even need any hacking of the
/dev/tty stuff.
--Greg
--
{ucbvax!hplabs | allegra!nbires | decvax!stcvax | harpo!seismo | ihnp4!stcvax}
!hao!woods
"... the heat come 'round and busted me for smiling on a cloudy day..."stephenf@elecvax.OZ (Stephen Frede) (08/31/84)
Re: writeable terminals by all allowing anyone to stuff you up. This is so obvious that I thought everyone must have fixed it. Of course you can't allow your terminal to be writable by all except in the most trusting of environments. A simple solution is to have all terminals group owned by a controlled pseudo user (eg "daemon" on our system, or "bin" if you like), and make the "write" command set-gid to that user. The real owner of the terminal can then turn on or off the group write permits as they like (via "mesg" or directly) and no-one can do funny things to your terminal, except by using "write", and even this, only when people allow it. Then the "write" program can be made to filter out control characters, which these days with supersmart terminals are just as painful as going into raw mode. Stephen Frede ...decvax!mulga!stephenf:elecvax
dhb@rayssd.UUCP (09/04/84)
For those of you who are really concerned about security, there is another hole in the systems related to sending escape and control characters to someones terminal. Since I haven't seen anything about it in this discussion, I won't mention it by name but any interested system administrators can send me a mail message and I will send back a description of the hole, how it works, and the fix. (please send the mail as root so that I know you are legit.) -- Dave Brierley Raytheon Co.; Portsmouth RI; (401)-847-8000 x4073 ...!decvax!brunix!rayssd!dhb ...!allegra!rayssd!dhb ...!linus!rayssd!dhb
mgk@ucla-cs.UUCP (11/22/84)
There have been several messages about preventing stty calls on someone else's terminal, but all of these involve the source code. Unfortunately, Microsoft does not distribute sorce to their Xenix system, nor can it be purchased at any price. Are there any solutions that do not require source? If not, does anyone know where I can get source for the programs in question (even V7 source; I'll modify it for Xenix myself) Michael Gersten Arpa: vss7101%uclavm@ucbvax Bitnet: vss7101%uclavm