full-disclosure - A short warning on the X11 Editres protocol

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 for Android: free password hash cracker in your pocket

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

Date: Tue May 31 22:37:52 2005
From: fw at deneb.enyo.de (Florian Weimer)
Subject: A short warning on the X11 Editres protocol

The xterm manual page contains a strongly worded warning about the
allowSendEvents configuration option:

| allowSendEvents (class AllowSendEvents)
|    Specifies whether or not synthetic key and button events
|    (generated using the X protocol SendEvent request) should be
|    interpreted or discarded.  The default is ??false?? meaning they
|    are discarded.  Note that allowing such events creates a very
|    large security hole.  The default is ??false.??

However, xterm is an Xt application and therefore speaks a
long-forgotten protocol called Editres.  As a result, any Editres
client (such as "editres") can instruct an xterm window to change its
allowSendEvents setting.  After that, it's possible to send
synthesized events to the xterm window and hijack the terminal.

Other Xt applications may have similar issues.  If an application is
SUID or SGID and does not drop privileges early in the startup
process, a privilege escalation vulnerability might exist (but it's
probably easier to exploit it by providing carefully constructed
resource settings from the beginning).

I'm not sure that the author of the paragraph was right to label this
as a security hole; certainly it's just a minor one.  However, the
xterm documentation should be updated.  (A previous attempt to resolve
this issue quietly had failed.)