Date: Thu, 10 Sep 1998 23:00:04 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Jon Hamilton <hamilton@pobox.com> Cc: Brian Behlendorf <brian@hyperreal.org>, andrew@squiz.co.nz, security@FreeBSD.ORG Subject: Re: terminal escape exploit (was Re: cat exploit) Message-ID: <Pine.BSF.3.96.980910225149.3574I-100000@fledge.watson.org> In-Reply-To: <199809110148.SAA18718@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
One will in fact even notice that most UNIX programs that pass text to other user's terminals (write, etc) filter out control characters specifically to prevent this behavior. For a while there was a fad ammong high schoolers (don't know about college students -- wasn't one at the tim) where escape characters could be stuffed into the announcement name presented by talked when a talk username was performed. It would set the alternate font for vt-style terminals. Needless to say, a hard reset in xterm fixed it, and then safety routines were added to clean up the output there also. No doubt people can get around this via DNS -- there are no doubt ways to pass arbitrary text to the terminal of the user by stuffing it in DNS names that get handed to the user. It may also be possible to pass text via syslog and so on. One cool trick if you have write access to the user's terminal device is to use the Tek control codes under Xterm to pop up a Tek display and perform cool graphics tricks. Draw a picture of a tree and have an arrow point at the roots or something. One extremely useful feature in Xterm is the mouse interaction -- program sends escape code, and xterm switches to sending stuff back to the terminal device when a mouse is clicked. This is how Pine does this (and other programs). If we disable escape codes, we do lose some useful behavior. On the other hand, for anyone still using serial terminals, this behavior cannot be disabled at all I would guess. Adding a new menu item in Xterm, a command line flag, and an Xresource that allowed users to disable this behavior might be useful, but I think turning it off loses too much functionality (especially given that it is not clear that the threat is actually a threat). Robert On Thu, 10 Sep 1998, Jon Hamilton wrote: > > In message <19980911003306.3455.qmail@hyperreal.org>, Brian Behlendorf wrote: > } At 09:19 AM 9/11/98 +1200, Andrew McNaughton wrote: > } >On Thu, 10 Sep 1998, Studded wrote: > } > > } >> It seems to me that a lot of people missed the point of one of the > } >> warnings that someone else posted in response actually. Don't use cat > } >> routinely to view files. Use more, or better yet less since less doesn't > } >> view binary files by default. > } > > } >It's not just cat that you've got to worry about. tail is another one. > } >How many people routinely use 'tail -f' to monitor log info that includes > } >potentially tainted content. > } > } Yeah, especially when trying to debug a problem that requires root. I do > } this. > } > } >The problem is not cat. It's xterm and other similar terminal programs. > } > } I agree. Even if the old-timers around here are saying "it's always been > } like that, just don't do it and it'll be all OK", I still see this as a > } design flaw, and would like to believe that "running arbitrary commands" > } can be prevented without preventing all the legitimate uses for escape > } sequences. > > One legitimate (if questionable) use _is_ to run arbitrary commands (well, > to output arbitrary text, the rest is all downhill from there). > Is it a good idea? Depends. Could someone who was sick enough to be > doing that do it another way? Almost certainly. But you can't change > the functionality without affecting _something_ someone is doing _somewhere_. > The question is whether the loss of functionality is outweighed by the gains. > Peoples' opinions as to the answer to that question are, um, not unanimous, > as you see. > > As has been suggested, the thing to do would be for someone who cares > to patch xterm (and rxvt, and anything else that does emulation of > virtually any intelligent terminal ever built) to permit a compile- (or, > better yet, run-time) option to turn off this feature. Submit the > patch to the maintainers of the code in question and argue with them > about it if necessary. > > -- > Jon Hamilton > hamilton@pobox.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980910225149.3574I-100000>