full-disclosure - Re: Terminal Emulator Security Issues

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <200302250807.08756.termulation@digitaloffense.net>
From: termulation at digitaloffense.net (H D Moore)
Subject: 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