l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
April 21: Google Glass
Next Installfest:
TBD
Latest News:
Mar. 18: Google Glass at LUGOD's April meeting
Page last updated:
2005 Mar 18 16:13

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)
Re: [vox-tech] xhost+: Why you should NEVER DO THAT
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Fri 18 Mar 05,  2:18 AM, Karsten M. Self <kmself@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@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
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
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.