[vox-tech] xhost+: Why you should NEVER DO THAT
Peter Jay Salzman
p at dirac.org
Fri Mar 18 04:54:50 PST 2005
On Fri 18 Mar 05, 2:18 AM, Karsten M. Self <kmself at ix.netcom.com> said:
> 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.
If my firewall blocks tcp/udp ports 6000-6007, can you tell me how my x11
events can be captured by someone other than my lovely wife and cat?
Pete
--
Save Star Trek Enterprise from extinction: http://www.saveenterprise.com
GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D
More information about the vox-tech
mailing list