COMMAND

    Xserver

SYSTEMS AFFECTED

    XFree Xserver

PROBLEM

    Chris Evans found following.  Here's a very interesting DoS  which
    Chris discovered  against XFree86-3.3.5.   He has  confirmation it
    also affects 3.3.6 and 4.0 (with a small difference, see below).

    Remote users can, by sending a malformed packet to port 6000  TCP,
    cause a victim X server to freeze for a couple of minutes.  During
    the freeze, the mouse does not move, the screen does not update in
    any  way.    Worse,  the  keyboard   is  unresponsive,   INCLUDING
    console-switch and kill-server key combinations.  For many  users,
    the machine might as well have crashed and a full reboot via  "the
    Big Red Button" will be performed.

    The precise  duration of  the freeze  is dependent  upon processor
    speed.  On a P2-350 Xserver  freezes for 3min 15s.  If  that's not
    long enough, queuing multiple  DoS packets can extend  that almost
    indefinitely.

    During the freeze, the X server consumes 100% CPU.  If you can get
    a shell  on the  afflicted machine,  the X  server can  be sent  a
    signal to restore  sanity, but getting  a shell is  not an options
    for users with one machine and no serial console.

    As  noted,  XFree4.0  is  also   vulnerable  but  with  a   slight
    difference.  Everything  freezes as above,  apart from the  mouse.
    This is no use for  recovery because the keyboard is  still hosed!
    Chris suspects the mouse handling is simply in its own thread,  to
    give the impression of a smoother, more perfomant X server.

    Not all builds of the X server are vulnerable.  To be  vulnerable,
    you need to build with "#define XCSECURITY".  All vendors to  thus
    far build with this however.  Quick check:

        strings /path/to/XF86_SVGA | grep "XC-QUERY-SECURITY-1"

SOLUTION

    The fact  that an  X server  will tend  to listen  via TCP on port
    6000 is a large risk (the Xserver runs as root with full  hardware
    permissions enabled).  However it is also an oft overlooked  risk.
    People  who  carefully  disable  all  their  daemons  for security
    purposes, often overlook the fact that X behaves as a server.  Any
    distributions  with  an  installation  class  of  "dialup user" or
    similar, should  really consider  starting X  with "-nolisten tcp"
    for these users.

    Any  bored  security  organisations  could  do worse than put some
    time into investigating the security of port 6000 of commercial  X
    servers.  This includes things like Exceed for Windows as well  as
    e.g. Sun's X server.  There is broad potential for worse than  DoS
    here...

    You can  run the  X server  with the  option "-nolisten  tcp" set.
    This option  causes the  X server  to not  listen connections from
    any  client.   To  use  this  option,  simply add it to serverargs
    variable in the /usr/X11/bin/startx  script ... then use  Xforward
    to listen on  port 6001 to  forward X traffic  to the UNIX  domain
    socket the X  server listens to.   Xforward will pop  up a  window
    asking whether you wish to accept the connection or not,  allowing
    you to have your cake and eat it too.  Xroute can be coaxed to  do
    this as well.