[16563] in Athena Bugs
No portable way to run an X server without network security risks
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sun Dec 13 16:42:35 1998
Date: Sun, 13 Dec 1998 16:42:21 -0500
From: Greg Hudson <ghudson@MIT.EDU>
To: xbugs@x.org
Cc: bugs@MIT.EDU
I would like to be able to run an X server on a Unixish workstation
such that it is accessable to local clients, without risk of
compromise by a remote attacker. This is not currently possible due
to the authorization model. The explanation is complicated; please
bear with me. As far as I know this problem applies to all current
versions of the X server.
One option I have is to use address authorization. Ideally, I would
only allow connections over the unix domain socket. There are some
known local security issues here, but I'm not concerning myself with
those. The problem is that, if only address authorization is being
used, the X server insists on allowing connections from INET:localhost
and INET:<result of gethostname()>. Most Unix-like operating systems
do not filter outside packets claiming to be from 127.0.0.1 or a local
interface address, and in fact most are also vulnerable to a
source-routing attack which makes it easy to spoof TCP connections
from the loopback interface.
Okay, you say, that's a little inflexible, but just start the X server
with an MIT magic cookie and have done with it. That's okay if I have
a good source of random bits, but if I don't (and I'm currently in a
case where I don't) that's arguably even worse: now even if my
operating system filters obviously forged outside packets, I'm
vulnerable to an attacker making a connection from any address at all
if they can guess the not-random bits I used to make my magic cookie.
xdm, for instance, uses the result of gettimeofday(), which isn't very
random and isn't particularly difficult to guess.
From looking at the code, I don't think there is any reason in
principle why it should be hard for the X server to start up allowing
only connections from the unix domain socket. Unfortunately, the code
in question is heavily conditionalized on operating system type and
has some entanglements with other functions of the server (the opening
of well-known sockets), so I cannot easily provide a patch. I suggest
a flag which removes everything but the unix domain socket from the
mandatory part of the address-based access control list.
From a "defense in depth" perspective, it seems wrong that I cannot
combine both address-based and token-based authentication types. Why
can't I accept only connections from the unix domain socket *and*
require them to use an MIT magic cookie, for instance? But that
involves a more radical change to the authorization model.
