[ http://www.rootshell.com/ ]

OS Affected:  Most, if not all, running xdm or CDE.

Problem:  Most implementations of xdm and CDE allow any host XDMCP
connection access by default. This, in of itself, is usually not a problem
since a valid username and password is still required for login. However,
for hosts configured to use TCP wrappers or Secure Shell with host access
control (hosts.{allow,deny}), or have disabled remote login access
altogether, the default xdm and CDE configuration allows access that
bypasses these controls.  Using a host configured as an X terminal (see
details below), an XDMCP connection can be made to get a login window.
The attacking host can then launch a brute force attempt to login. And,
I believe most operating systems do not log the failed attempts. Also, xdm
and CDE ignore which device root is allowed to login, so root can login
remotely where root would normally be restricted to console login only.

[Side note: Verifying valid usernames can be done on hosts running CDE
for those users NOT using the default CDE desktop, like OpenWindows. The
CDE login window displays a pixmap of the last desktop the user used.
Trying different usernames and seeing if the desktop pixmap changes
indicates the username is valid.]

Solution:  Filter port 177/udp at the router, or edit Xaccess and
precede hostname or pattern entries with '!' to exclude them, or include
only those hosts allowed to connect to the display.

Default Xaccess file:
[snip]
# In all cases, xdm uses the first entry which matches the terminal;
# for IndirectQuery messages only entries with right hand sides can
# match, for Direct and Broadcast Query messages, only entries without
# right hand sides can match.
#

*                                       #any host can get a login window

#
# The nicest way to run the chooser is to just ask it to broadcast
# requests to the network - that way new hosts show up automatically.
# Sometimes, however, the chooser can't figure out how to broadcast,
# so this may not work in all environments.
#

*               CHOOSER BROADCAST       #any indirect host can get a
[snip]

Change to:
[snip]
# In all cases, xdm uses the first entry which matches the terminal;
# for IndirectQuery messages only entries with right hand sides can
# match, for Direct and Broadcast Query messages, only entries without
# right hand sides can match.
#

!*                                       #any host can get a login
window

#
# The nicest way to run the chooser is to just ask it to broadcast
# requests to the network - that way new hosts show up automatically.
# Sometimes, however, the chooser can't figure out how to broadcast,
# so this may not work in all environments.
#

!*               CHOOSER BROADCAST       #any indirect host can get a
[snip]

Exploit (well, not much of one):
(Credit goes to Simon Greaves for his tips on how to setup your host as
an X terminal.)

Setup your host as an X terminal to connect to another host via
XDMCP by doing the following:

For most xdm and CDE installations:
1. Remove, or comment, the local display line in the Xservers file. For
SunOS and Solaris, it's located in /usr/openwin/lib/xdm; for RedHat
Linux (and probably others using XFree86), it's in /etc/X11/xdm; for
CDE, copy /usr/dt/config/Xservers to /etc/dt/config/Xservers and modify;
for other systems look in /usr/lib/X11/xdm or /usr/X11/lib/xdm.

2. Configure chooser entries in the Xaccess file to include the victim
host. (For CDE, copy /usr/dt/config/Xaccess to /etc/dt/config/Xaccess
before modifying.)
%hostlist       victim1 victim2
*               CHOOSER %hostlist       #

3. Start xdm (or CDE) and the X server. Note: Kill the current X server
if it is running.

$> cd /usr/openwin/lib/xdm
$> xdm -config xdm-config
$> X -indirect victim1

For CDE (on Solaris 2.x):
$> /etc/rc2.d/S99dtlogin start
$> X -indirect victim1

If the connection is successful, you should see a popup chooser window
with a list of hostnames that allow connections. Selecting one of the
hostnames gives the remote host's login screen. Again, login still
requires a valid username and password for access.

[AFAIK, this problem was first mentioned by Zygo Blaxell, 3Sep96,
on Bugtraq. I'm mentioning it again (with more detail) to stress the
importance of the problem since it can bypass host access controls in
place, and some system administrators may not be aware of it.]

--
Eric Augustus
augustus@stic.net
-----------------