On Sat, 13 Mar 2004, James K. Lowden wrote:
> I have to admit I don't understand the attack, if that's what it is.  So,
> the filename has some magic sequence that the terminal reacts to, and it
> spits it out on the screen.  Unless the filename is a whole program that
> somehow gets xterm (presumably) to do something, the only consequence is
> xterm output on the screen.  What am I missing?  

I think you are missing the definition of an "answerback" message in
this context.  Some terminals contain a configurable message which
can be sent to the host (as if it were typed on the keyboard) on
request.  This was once intended to help the host to identify what kind
of terminal was plugged into a serial port.  Some terminals allow a
specially formatted message from the host to *change* the answerback
message.

The attack is:

  1. Create a magic sequence that tells the terminal
     "set your answerback message to 'rm -rf /\n'"
     (or any other dangerous command).
  2. Create a magic sequence that tells the terminal
     "send me your answerback message".
  3. Send message 1 and message 2 to the terminal.
  3.1. Create a file whose contents contain the magic sequences,
       and wait for root to cat the file.  (Note that more(1) and
       less(1) are not vulnerable.)
  3.1. Create a file whose name contains the magic sequences, and
       wait for root to ls the directory.  (Note that "ls -q" protects
       against this.)
  3.2. Create a web page, email message, or whatever, which contains
       the magic sequence, and hope that root reads the message in
       an insecure way.  (Most mail readers and web browsers protect
       against this.)

> At any rate, the problem isn't limited to ls(1) in any way.

True, but root is much more likely to run ls(1) in a random directory
than to do anything else that exposes this vulnerability.  That's why
"ls -q" is the default when output is to a terminal.

--apb (Alan Barrett)