Re: Hostile X servers

[zblaxell () myrus com (Zygo Blaxell)]

Quoted from Perry E. Metzger:
> Zygo Blaxell writes:
> > For those of us who've been paying attention for the last six months,
> > this can be no surprise.  However, this makes me think of other X-related
> > attacks.
>
> There are dozens of X attacks. My generic way to stop them these days
> is to compile the X server without TCP support. Yes, this still makes
> users vulnerable to others logging in to their workstation, but it
> does totally eliminate the threat of others on the network hitting
> them. It does perhaps reduce functionality somewhat, but you can get
> it back with things like ssh to provide tunnels for applications...

That will prevent someone from attempting to run *hostile clients on your
X display*.  This type of attack involves a single malicious client
attempting to attack other clients which use the same X server, or more
often the X server itself.  This is the attack everyone seems to know about,
judging from the amount of stuff people have written about it.  The
preferred defense is to prevent hostile clients from talking to your X
server, period.  The next best defenses involve various labelling and
compartmentalization techniques in the X server, but these aren't portable
to all X servers, and even the trivial anti-spoofing parts of the protocol
(like synthetic event bits) are incorrectly implemented in some X servers,
making them even *less* secure than a correct implementation of the
vanilla X protocol.

If someone is trying to attach a *hostile X server to your X clients*,
then no amount of changing your own X server will help you.

Example 1:  attacker uses XDMCP to get a login window from your host on
their X display, plus any clients you may run automatically before login
(e.g. xset, xconsole, or any number of "useful" programs like Workman,
xclock, or xload).  You can modify your Xaccess file to prevent xdm-based
network login.  If you don't run xdm at all, you're safe.

Example 2:  User A runs 'xhost +' so that user B can open windows on user
A's display for a hypothetical user-to-user messaging or chat program,
or perhaps a multi-player game.  Of course user B can now attack user A
(hostile client attack) via any clients that user A is running on display
A, or by reading the keyboard, etc. etc.  However, user A can also attack
user B (hostile server attack) via any clients that user B is running
on display A.

Note that user B has not given away access to her X server (actually,
user B doesn't need to *have* an X server, just vulnerable clients running
on A's display), but user A is able to attack B via X protocol
nonetheless.

The nature of the attacks varies according to libraries used and the
capabilities of the client.  Buffer overrun or quoting bugs in the client
or the client's library are possible in all clients; simple clients with
simple libraries are the easiest to verify, while hairier clients like
window managers or high-level widget toolkits have lots of places to hide
a bug exploitable from the X server (remember that malformed X server
protocol is allowed for these attacks ;-).

At the other extreme of the spectrum, clients like Tk not only give away
almost total control of the client to the X server (or a hostile client
on a benign X server), but:  throw in a programming language with access
to network, filesystem, and arbitrary shell commands; document it; call
it a feature; and enable it by default.

ObWhatWereThey_Thinking_: Surely it makes better design sense to allow
receivers of messages to define a procedure that takes a message as
a parameter, and invoke that procedure whenever a message arrives,
than to allow *any* sender to invoke *any* command in the target's
Tcl interpreter?  If it's really necessary to do this, one could always
define the receive-message command as a wrapper around 'eval' to achieve
the same effect; however, with the current design, you have to give away
all access to your application, or disable X-based IPC entirely.


--
Zygo Blaxell. Unix/soft/hardware guru, was for U of Waterloo CS Club, now for
(name withheld by request). 10th place, ACM Intl Collegiate Programming Contest
Finals, 1994.  Admin Linux/TCP/IP for food, clothing, anime.  Pager: 1 (613)
760 8572.  "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong