Great Circle Associates Firewalls
(July 1994)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Using Xnest for X Across a Firewall
From: "Brian L. Kahn" <blk @ vanity . mitre . org>
Date: Fri, 22 Jul 1994 11:09:56 -0400
To: firewalls @ greatcircle . com
Posted-from: The MITRE Corporation, Bedford, MA

Using Xnest for X Across a Firewall
===================================

Xnest is an X server implementation which runs within an X window.  It
is included as part of the X11R6 distribution.  Xnest may be useful to
system administrators who seek to allow safe X connections across a
firewall.

Xnest is intended to be used as a test environment for X development.
Experimenting with a new window manager (WM) or server extension can
be difficult because the debugger, editor, and other test tools use X
for their user interface.  Xnest solves the problem by providing a
nested X server which is confined to a single X window.  Xnest listens
at a different port from the main server, typically acting like a
second display accessed by setting HostName:1 in the DISPLAY variable.
The geometry of the toplevel Xnest window are taken as the dimensions
for the Xnest display screen.  An X client cannot see any difference
between Xnest and a more conventional server.

Xnest is in fact the standard MIT X server with the hardware dependent
code layer implemented to use Xlib calls instead of directly accessing
the hardware.  This allows developers and tinkerers to experiment with
alternate window managers or configurations without restarting the
main server.  The main X server will continue to operate normally,
even if the window used by the Xnest server is hung or otherwise
non-functional.

The purpose of Xnest is to provide an X environment which is isolated
from the main X server.  The isolation provided by Xnest can be
applied to a different situation - safely running X connections across
a firewall.  Simply running X across the firewall can be accomplished
using any of several forwarding agents: xroute, xmon, xforward, or
others.  The problem is safety; once an untrusted client has connected
to your server it can eavesdrop on keystrokes, read windows, or
disrupt operations in various ways.  For users behind a protective
firewall who want to run remote clients, the Xnest server program may
provide the necessary protection for security and continuous service.


DISCLAIMER and CAUTION
======================

My analysis of Xnest is limited by available time and funds.  I have
reviewed the code provided in the initial X11R6 release and I have
performed a number of tests based on my knowledge of the X protocol.
I have not performed a detailed analysis of the Xnest code or the
larger body of X11R6 server code.  There may be implementation flaws
in either set of code, and there may be issues at the X protocol level
which have escaped me, so "caveat emptor".  Neither myself nor my
company can be held liable for any errors here.  The purpose of this
message is to share some experience and guide others in their own
investigations.


Safety Policy
=============

Xnest provides a complete X environment nested within a regular
X server.  To keep the environments straight I will refer to the two
as "the server" and "Xnest", even though Xnest is in fact an X server
in its own right.

Xnest operates as a separate virtual environment.  Xnest doesn't allow
interactions between Xnest clients and server clients.  Xnest is
almost completely isolated from the server; the only overlaps are the
fonts and physical device configurations.

Xnest maintains all X resources for it's clients.  Pixmaps, windows,
atoms, et cetera are kept in the Xnest data space and are rendered
into the Xnest root window by Xnest routines.  The only X resources
maintained by the server are the loaded fonts.  Text is rendered by
the server, not by Xnest; without this approach Xnest would have to
load all fonts and paint the text strings as bitmaps, resulting in
very heavy X traffic for text.

In most ways the keyboard and mouse are virtual devices which are
shadowed by Xnest.  The keyboard is only "connected" to Xnest when the
Xnest root window has been given the keyboard focus by the window
manager, and the mouse is only "connected" when the cursor is in the
Xnest root window.  At other times, the mouse and keyboard maintain
the state they had when last "connected".  Key and mouse grabs work
within this context.  Active and passive grabs are restricted to
Xnest and do not affect the server.  Queries regarding device state
reflect the history as seen by Xnest.  Xnest also maintains it's own
device maps.

While the devices are virtualized in some ways, the device
configuration information carried by ChangeKeyboardControl and
ChangePointerControl are at too low a level for Xnest to handle
independently from the server; those two X requests are forwarded to
the server from Xnest.  These are the settings for LEDs, keyclick,
autorepeat, beep, pointer acceleration and threshold normally handled
by the xset utility.  The unfortunate result is that Xnest may change
the settings familiar to the user, and it is tricky to keep Xnest and
the server in synchronization.


Analysis
========

* Summary: The isolation provided by Xnest is well suited for
protection against possible privacy and denial-of-service attacks.

* Features: Xnest can be compiled with little effort from the X11R6
MIT distribution.  It provides a conceptually elegant mechanism for
safe execution of untrusted X clients.  The user gets immediate and
fully X11R6 compatible access to the Xnest clients by simply moving
into (or selecting) the Xnest window on the desktop.  The Xnest
clients have access to a full X environment, but these clients cannot
disrupt normal desktop operations or access the resources created by
other desktop clients.

* Misfeatures: When considered for use as a firewall safety mechanism,
Xnest has several drawbacks.  In brief, the problems are that Xnest
is: newly released, complex, X11R6, intended for testing, best run
co-located with the X server, and resource intensive.

 - Newly Released: The reliability of newly released software is uneven.
Some programs are robust from the start, others need years of bug fixes.
There are numerous updates for each release of X11.  The manual page for
Xnest has a BUGS section warning of memory leaks and "frequent crashes"
which need to be worked out.  Xnest may hold up in the field; my tests
have crashed Xnest twice, each time under cruel and unusual treatment.

 - Complex; Safety critical software should be as small as possible to
allow complete specification and analysis.  Xnest is nearly as large and
complex as the server, well over 2MB in a typical installation.  There
may be flaws in the code which could be exploited.  On the good side,
the server software has been refined over the years into layers for
portability.  The only code unique to Xnest is in the hardware layer.
This is a much smaller body of code with a relatively clean interface.

 - X11R6: Xnest is part of the R6 release.  Xnest itself is an X11R6
server, although it can be run nested under an R5 (and possibly earlier)
release server.  The problem with the new release is simply the build
process and the library installation.  If you aren't running R6 yet, you
must install and build the new release on the target platform to get an
Xnest executable.  If you go this route, you can compile with static
linking and retain only the executable.

 - Intended for Testing: As a test environment for developers Xnest is
just fine, but the interface is a bit unfriendly for general users.
Colormaps are not shared, so the colors of all other windows will be
disrupted when entering an Xnest window.  Not all window managers
handle colormaps properly, which complicates the problem.  If the
windows within Xnest need management then there must be a WM running
for the Xnest virtual display, which means the user suffers the
confusion of nested WM interfaces.  The Xnest window may be resized to
a smaller size, but not to a larger size; if it is reduced, the Xnest
clients will still see the virtual screen at the original larger size.
Xnest resets the mouse and keyboard devices to it's own settings,
which makes starting Xnest rather tricky; for example, the user's
autorepeat settings are typically disrupted.  And of course, there can
be no cut-and-paste between Xnest clients and other clients.  There
may even be several selections showing on the screen at once.

Xnest is not meant to be security software.  This is not a problem in
itself, but may be one in the future.  Xnest could be changed in a
future release to support a different policy.  There might be little
mention of such a change because the existing policy is not critical
to operations.  For example, if Xnest works better for testing
purposes by reflecting the true state of the keyboard for each
XQueryKeymap call, the change might slip by unnoticed.

 - Best Run Co-located: Xnest creates heavy X traffic, so it is a good
idea to have Xnest run on the same host as the server.  In general,
Xnest generates more traffic than the clients it serves because the
Xnest server renders the client images.  On the other hand, the X11R6
distribution won't compile under MSWindows or DOS or Mac OS, so sites
running X servers on PCs cannot co-locate.

Moreover, running the protection software on each system is contrary to
the firewall philosophy.  For most firewall architectures, one of the
main goals is to minimize reliance on proper configuration of the
protected systems.  The firewall gateway should be a focus point for
administration and control of the protection mechanisms.  Relying on
co-located Xnest for privacy or denial-of-service protection weakens the
firewall concept.

 - Resource Intensive: Not so bad, considering.  Xnest is an server, and
it consumes resources in kind.  This is certainly a concern if you
expect to run a slew of Xnest servers on your firewall boundary host.
Resource requirements may be the limiter for this technical approach.

Here are some raw numbers taken from my test platform consisting of a
Sun IPX running SunOS4.1.3, 32MB RAM, 64MB swap, MIT X11R5 server, ctwm
WM with four busy virtual desktops:

mitre-host:xnest[111] ldd Xnest.static
Xnest.static: statically linked
mitre-host:xnest[112] size Xnest.static
text    data    bss     dec     hex
2007040 188416  50512   2245968 224550
mitre-host:xnest[113] ps v | head -2  
  PID TT STAT  TIME SL RE PAGEIN SIZE  RSS   LIM %CPU %MEM COMMAND
16544 co S     7:39  0 99    857 6280 1704    xx  0.0  5.6 Xsun
mitre-host:xnest[114] ps gv | grep nest
17350 p4 IW    0:03 99 99     32  784    0    xx  0.0  0.0 Xnest.static
mitre-host:xnest[115] DISPLAY=:1; xterm& xterm& xterm& lucid-emacs&
[1] 17506
[2] 17507
[3] 17508
[4] 17523
mitre-host:xnest[116] ps gv | grep nest
17350 p4 S     0:04  2 11     51  928 1052    xx  0.0  3.5 Xnest.static

* Vulnerability: Multiple clients connected to an instance of Xnest
may interact normally, with all the problems of a normal X server.

This vulnerability will allow attacks from one client against another
on the remote host or hosts.  In general this kind of attack is not a
concern for privacy or denial-of-service protection within the
firewall, but it is likely to be a serious concern for sites cautious
enough to maintain a firewall.  A scenario:
  Albert User sits in front of an X windows workstation within the
  firewall run by the prestigious MIGHTY Corporation.  Al is working
  with technical staff at Hugh Sezz University (SezzU) and a private
  firm, A Research Group (ARG).  Al is running an xterm from each
  site, displaying in Xnest on his screen.  A bored student at SezzU
  quietly connects to Al's Xnest server and sends synthetic keyboard
  events through Xnest to the xterm client at ARG, exploiting some
  security flaw on ARG's host.  Xnest protects the systems within the
  MIGHTY firewall, but ARG is upset that a MIGHTY host was used to 
  break into their system; unkind public name-calling ensues.

* Operation: Maintain careful control over the clients connecting to
Xnest.  Any of the five X11R6 access control mechanisms may be used
(X11R6 adds support for Kerberos).  An intermediary may be used to get
user authorization for each connection (i.e., xforward from DEC-CRL)
or to limit the number of clients.  Xnest itself could be modified to
limit the number of clients.  Caution: be certain that clever users
can't accidentally bypass the protections by connecting both inside
and outside clients to Xnest.

* To Be Done: Some utilities or extensions would improve the usability
of Xnest for this application: synchronize colormaps at startup;
automatic "shrink-to-fit" for single window clients; trusted transfer
agent for user-authorized cut-and-paste operations; gateway based
daemon to start up Xnest at user's request, returning the Xnest
virtual display name (a la Cheswick and Bellovin).


Prognosis
=========

Xnest can solve some problems now, and it might be adapted and polished
to serve a wider audience.  MITRE is considering internal use of a
modified version of Xnest in the short term, and is continuing work on a
more sophisticated policy enforcement module for X which is less
resource intensive.  Both solutions are promising.



Brian L. Kahn   "In theory, there is no difference between theory and practice.
blk @
 mitre .
 org    In practice, of course, there is."

 




Indexed By Date Previous: Re: prevalence of sniffing ?
From: barnett @ alydar . crd . ge . com (Bruce Barnett)
Next: Re: prevalence of sniffing ?
From: Ken Presser <WINSTON1/BALIWS/kpresser%Sara_Lee_Intimates @ mcimail . com>
Indexed By Thread Previous: firewall-introduction.ps.Z
From: hle @ qualix . com (Hung Le)
Next: SEAL documentation
From: paul @ hawksbill . sprintmrn . com (Paul Ferguson)

Google
 
Search Internet Search www.greatcircle.com