l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2005 Mar 21 11:34

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
[vox-tech] xhost+: Why you should NEVER DO THAT
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vox-tech] xhost+: Why you should NEVER DO THAT

Mark Kim apparently insists on dispersing bad advice regarding use of
xhost + to allow remote X11 access.

I suspect most of us pride ourselves over the fact that GNU/Linux can be
made more secure (and generally is more secure as configured) than
legacy MS Windows systems.  This doesn't mean you can't blow the whole
concept with some really bone-headed actions and advice.  xhost + is
among the more blatant abuses.  It flies in the face of well over a
decade of both administrator advice and official warnings.

A little bit of history and technology:

    The X Window System is a _networked_, _multi-platform_, _graphical
    dsiplay system_.  It does _not_ have an inherent security model,
    though several have been tacked on over the years.  These include:

     - xhost:  host-based access control (a/k/a no access control)
     - MIT-MAGIC-COOKIE-1:  (cleartext) token-based control.
     - SSH X11 tunneling:  encrypted, authenticated access control

    You'll find that most modern X servers put a few additional
    roadblocks in place, which for the reasons stated previously, I
    won't mention explicitly, and would appreciate others not either.
    Research on your own and identify why there are security issues.

Short answers:

    Remote X11 Access:  Use SSH

    If you want to provide or allow remote access to an X display or
    client, use SSH with X11 tunelling.  Read your client and server
    documentation for details.  Generally:

       # Allow multiple commandline or X commands
       ssh -X remotehost


       # Single command run on a forked SSH session
       ssh -Xf remotehost <command>

    are what you want.

    Running (local) X applications as root

    The 'sux' (su X -- superuser X) command on some distros provides for

        sux <command>

    If this isn't available, a slightly longer alternative is:

      - Identify your non-root user's X display:  echo $DISPLAY
      - go root:  'sudo bash -l' or 'sudo su -'
      - set root's display:  export DISPLAY=<user's display>
      - merge user's xauth file:  xauth merge ~<user>/.xauthority
      - run command(s)

X and network access

    X is a wholly network-transparent protocol.  This is useful (users
    and the applications they run need not be at the same location) and
    leads to some interesting applications (Xnest), but also results in

       Any user with network access to an X display can present or snoop
       any arbitrary content from that X display.

    At its simplest level, this means it's possible to trivially take
    screenshots of a remote X display.  It's also possible to write
    clients which track and record keystrokes and other actions on the
    screen.  More deviously, a malicious client could present its own
    content to be displayed, say, to fool a user into entering
    sensitive information on a misrepresented dispaly -- analagous to
    the common phishing data divulgance attacks today.   A password
    dialog, for example.

    The other issue with X is that network data are not encrypted or
    (barring add-ons) authenticated.  On network segments open to
    snooping (wireless networks, hubbed networks, third-party-controlled
    segments), all X traffic can be intercepted or subject to other
    attacks such as man-in-the-middle.

    With ever increasing network interconnections, security issues on
    common network clients (particularly Microsoft systems), and the
    ready availability of "bootable" network security and spying tools
    (Trinux, Knoppix, LNX-BBC), trust in any but the smallest and most
    tightly controlled network segments should be minimal.  "The
    Intranet is dead".

Remote X Access Controls

There are three general control mechanisms available for X sessions:

  - xhost (don't use)
  - MIT-MAGIC-COOKIE-1 (provides minimal protection)
  - SSH tunnelling (strongly recommended)

xhost access control

   The simplest form of control is to restrict access to named hosts.
   Hosts are added with the command:

      xhost +<hostname>

   ...or removed with:

      xhost -<hostname>

   All hosts can be removed with:

      xhost -

   Its counterpart is among the major problems, but it's not the only
   one.  The xhost concept has several major weaknesses:

    - Any user on a named host is allowed access (Secure RPC allows
      user@host specification, this is not in widespread use).

    - Spoofing the hostname can allow an unauthorized host access.  This
      is possible via numerous name resolution hacks.

    - The notation 'xhost +' is equivalent to _no_ host restrictions,
      and allows _any_ host to access the X display to present,
      intercept, or modify data and/or graphics.

   xhost is subject to many of the same abuses as the rsh remote access

   Any use of xhost should be limited to troubleshooting and/ testing
   only, if at all.

MIT-MAGIC-COOKIE-1 access control

   A slightly higher level of control is provided by using a 128 bit
   token, established in session startup, and passed with each X

   The token itself is vulnerable to interception on networks in which
   shared segments exist (e.g.:  wireless, hubs, third-party segments).

   Security if this system requires appropriate permissions control of
   .xauthority files (no group/world read/write access).

   Cookies do not encrypt traffic:  any network traffic is still subject
   to interception.


SSH X11 Forwarding

   SSH can address the following problems with use of X over networks:

   - Authentication
   - Access
   - Disclosure

   SSH allows tunneling of one protocol within anther.  The capability
   for X11 forwarding is built in to most modern SSH implmentations.
   Effectively a private, encrypted, authenticated session is created
   between local and remote hosts.

   SSH connections are authenticated based on user tokens (passwords,
   RSAKey authentication, or other methods).  Other users cannot gain
   access to the session.

   SSH sessions cannot be hijacked, once established. 

   SSH connections are encrypted.  Data in transit cannot be feasibly
   sniffed, even over open or shared network segments.

X Security Bulletins & Resources

Bulletins and resources concerning X Window System security.

    UNIX Security Checklist v2.0

    12.1 X Security - General

    - DO read the man pages for xauth and Xsecurity. Use this
      information to set up the security level you require.

    - ENSURE that the permissions on /tmp are set to 1777. (i.e. the
      sticky bit should be set) The owner MUST always be root and group
      ownership should be set to group-id 0 or "system". If the sticky
      bit is set, no one other than the owner can delete the file
      /tmp/.X11-unix/X0, which is a socket for your X server. Once this
      file is deleted, your X server will no longer be accessible. See
      C.14 for example commands to set the correct permissions and
      ownership for /tmp.

    - DO use the X magic cookie mechanism MIT-MAGIC-COOKIE-1 or better.
      With logins under the control of xdm (see 12.2), you can turn on
      authentication by editing the xdm-config file and setting the
      DisplayManager*authorize attribute to true. When granting access
      to the screen from another machine, use the xauth command in
      preference to the xhost command.

    - DO not permit access from arbitrary hosts. Remove all instances of
      the xhost + command from the system-wide Xsession file, from user
      .xsession files, and from any application programs or shell
      scripts that use the X window system.

    - CONSIDER encrypting your X network traffic, especially if you run
      remote clients locally. Ssh is a useful method.

    - CONSIDER configuring workstations to disable listening for
      incoming X sessions over the network. This is done on some
      operating systems by using the -nolisten tcp option. You should
      consult your specific operating system's documentation for
      specific instructions. 

    UNIX Configuration Guidelines

    Inappropriate network configuration file entries

    Several vendors supply /etc/hosts.equiv files with a '+' (plus sign)
    entry. The '+' entry should be removed from this file because it
    means that your system will trust all other systems. Other files
    that should not contain a '+' entry include all .rhosts files on the
    system. These files should not be world-writable.

    If your /usr/lib/X11/xdm/Xsession file includes an 'xhost' command
    with a '+' entry, such as

         /usr/bin/X11/xhost +

    remove that line. (Note that the 'xhost' command may be in a
    different directory tree on your system.) If such a line remains
    intact, anyone on the network can talk to the X server and
    potentially insert commands into windows or read console keystrokes.

    October 31, 1996

    Anyone running xhost+ who has a valid IP of another user running
    xhost+ can capture their screen image. Using a simple script and the
    domain of an IP address, an individual can increment through
    multiple IP addresses, and determine which computers are running
    xhost+. An attacker can then setup a script to screen capture at
    given intervals throughout the day and save the images for review.
    This vulnerability is undetectable and can be run at any time.

    Enabling X11 Access Control (Fixing xhost +)

    The number 1 rated high risk system vulnerability noted by the
    recent ISS audit of BNL was the use of "xhost +" or an open X
    display. Using "xhost +" allows anyone the ability to watch your
    keystrokes, capture windows and insert command strings into your
    windows. This situation is particularly bad when you have root
    access to a machine.  There is no legitimate reason to run "xhost +".

    Vulnerability Note VU#704969
    X servers may have insecure default configuration of xhosts

    Many X Windows emulators are configured to allow any remote X client
    to open windows on the X server. On command-line based systems the
    equivalent configuration is generated by executing "xhost +". This
    configuration is insecure because attackers may be able to connect
    to the X server and monitor keystrokes or inject commands into X
    windows sessions.

    CERTŪ Advisory CA-1995-07 SATAN Vulnerability: Password Disclosure

    Avoid using the xhost mechanism, but use xauth and MIT magic cookies
    or better. Otherwise, unauthorized users can see and manipulate
    everything that happens with the screen, keyboard and mouse. Of
    course, this can also be a problem when you are not running the
    SATAN program at all.

    SANS PC Xwindows Security Notice 2004/10/06

    It has come to our attention that some University IP space has
    recently been scanned for TCP port 6000, used to serve up
    X-sessions. We have reason to believe that many WINDOWS computers
    running various X software (Xwin32, eXceed, and others) are being
    compromised by having the equivalent of "xhost +" set.


    X, when run with access permissions disabled (e.g., in "xhost +"
    mode) will happily provide access to Xevent queues to anyone who
    requests it. Since X events include keystrokes, window resizing and
    (re)drawing, mouse movements, etc. (pretty much any user interaction
    that comes to mind), it's *TRIVIAL* to do things like take screen
    snapshots, move or resize windows, grab keystrokes, etc. We have
    positive evidence from other Universities that keystrokes *are*
    being captured.

Thank you.


Karsten M. Self <kmself@ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    The question is not whether I'm paranoid, it's whether I'm paranoid enough.

Attachment: signature.asc
Description: Digital signature

vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.