[vox-tech] xhost+: Why you should NEVER DO THAT
Karsten M. Self
kmself at ix.netcom.com
Fri Mar 18 02:18:27 PST 2005
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
<commands>
or
# 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
this.
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
vulnerabilitys.
Specifically:
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 at 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
commands.
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
transaction.
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.
http://csrc.nist.gov/publications/nistpubs/800-7/node90.html
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
https://www.cert.org/tech_tips/usc20.html
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
http://www.cert.org/tech_tips/unix_configuration_guidelines.html
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.
DEPARTMENT OF ENERGY INFORMATION SECURITY RESOURCE CENTER
PACIFIC NORTHWEST NATIONAL LABORATORY
ADVISORY NOTICE No. 4
October 31, 1996
XHOST+ REMOTE SCREEN CAPTURE
http://www.pnl.gov/isrc/advisory-notices/advis4.stm
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 +)
http://www.phy.bnl.gov/cybersecurity/xhost_plus.html
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
http://www.kb.cert.org/vuls/id/704969
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
http://www.cert.org/advisories/CA-1995-07.html
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
http://cssceb.ece.ohiou.edu/security/pc-xwin-notice-20041004.html
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.
Peace.
--
Karsten M. Self <kmself at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://ns1.livepenguin.com/pipermail/vox-tech/attachments/20050318/2bb1e861/attachment.bin
More information about the vox-tech
mailing list