levy@ttrdc.UUCP (Daniel R. Levy) (11/10/86)
In article <5256@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: >In article <2481@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >> Maybe I'm missing something obvious, but why are block-mode >>terminals a security problem? >The problem is that these features allow anyone who can transmit >more-or-less unmolested information to the terminal to force-feed >input from that terminal, which so far as UNIX knows was typed by >the logged-in user. This can be protected against to some degree >by changing the "write" utility, mail-reading interface, etc. to >not send ESC and other possibly harmful characters unmapped to the >terminal. However, "cat file" can still trip a mine like this. As a matter of fact, unless the /dev device associated with the terminal is world-unwriteable (mesg n), simply "cat hacker.file > /dev/console" is a dangerous possibility for a logged-in-as-root block-mode terminal. SO WHAT if "write" is prissy about what it sends? :-) ("write" is normally not setuid root anyway, so fixing it to filter out escape sequences wouldn't help anything that a "mesg n" wouldn't also help.) I think the big trick with doing it that way (or with mail) would be to do it so that the person using the terminal notices nothing out of the ordinary when the dastardly deed actually happens. Especially with mail, where the sender of the mail is shown! -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, go for it! allegra,ulysses,vax135}!ttrdc!levy
gwyn@brl-smoke.ARPA (Doug Gwyn ) (11/11/86)
In article <1307@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >As a matter of fact, unless the /dev device associated with the >terminal is world-unwriteable (mesg n), simply "cat hacker.file > /dev/console" >is a dangerous possibility for a logged-in-as-root block-mode terminal. SO >WHAT if "write" is prissy about what it sends? :-) ("write" is normally not >setuid root anyway, so fixing it to filter out escape sequences wouldn't >help anything that a "mesg n" wouldn't also help.) Oh, I was taking for granted that one had already taken care of world- writable /dev/tty* inodes anyway. "cat nuisance >/dev/ttyXX" has long been a possible source of discomfort. BRL UNIXes require use of special privileged "write", "wall", etc. that honor the convention that the "x" bit (not the usual "w" bit) indicates writability. 4.3BSD seems to have the idea that set-GID "tty" group processes should be used to write other people's ttys. Undoubtedly other such approaches are possible. Certainly you need to take care of this, as well as having "write" etc. filter escape sequences, to avoid the block-mode terminal problem. By the way, a related issue is the need to distinguish between the following "mesg" states for a tty line: - anyone may send me a message (typical normal shell) - only a system administrator may send me a message (to get relief from bad citizens, for example) - NObody (other than myself) is allowed to send me anything (special protocol port, downloaded layer, or hardcopy device busy printing a document) as well as the following distinction: - this is the tty line to send me messages on (communication layer) - this is NOT where I want messages sent (other layers) Not all combinations of who(utmp)/mesg/write/wall support all these distinctions; back when almost everyone had limited expectations for ttys, it wasn't important, but now that networking and windowing systems are widespread, this needs to be dealt with.