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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 31 May 2005 23:37:37 +0200
From: 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.)
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -

Powered by blists - more mailing lists