Re: request CVE id: insecure handling of DISPLAY in rxvt

["Bernhard R. Link" <brlink () debian org>]

* Robert Buchholz <rbu () gentoo org> [080327 03:30]:
> The same issue also exists in:
> aterm, tested 1.0.1
> mrxvt, tested 0.5.3
> multi-aterm, tested 0.2.1
> rxvt-unicode, tested 8.3 and 8.9
> wterm, tested with 6.2.9

These seem all to be rxvt forks. (At least aterm and wterm are, I'm
judging the rest by their names).

> eterm, tested 0.9.4

That seems to be an independent buggy implementation.
(I've sent a patch to the Debian bts at http://bugs.debian.org/473127)

> This is almost half of the terminal emulators I tried. There are
> probably tons of other X applications doing this, not all with the
> impact of a shell, but many allow starting other programs one way or
> another.

I'm really quite suprised to see this, as an application has to
actually do something to end up having this problem.

> Reading the attack vector, I would consider it a vulnerability, but
> looking at the amount of programs that fall into this category, I'm
> worried how many programs do this and if the low impact is really worth
> fixing all of them.

Clicking fast enough to enter some commands is not that easy, and not every
program will allow direct entering of commands, so I guess are most
programs are only usability problems (you get to wait 3 to 10 seconds
before you get an error message when by mistake starting it via an ssh
without -X), and a malicious fake X server would most likely be prepared
for every single program (to reject unexploitable programe early so it
is not noticed, and to send the keyboard events to the right window), so
most programs might not be that much of a problem.

On the other hand, having so many different terminals with almost
identical source might make it even easier to write one exploit that
can cope with all of them.

Hochachtungsvoll,
        Bernhard R. Link