I believe I have discovered two potential problems with xdm in XFree86
3.3.  I can confirm that both problems exist on a i486 running Red Hat
Linux 4.2 with a 2.0.30 kernel, but from examining the source code I
imagine these problems exist on all platforms running xdm from XFree86
(and possibly xdm from other X distributions).

The first problem is a denial of service attack that can easily be
mounted against xdm.  By telneting to the TCP port opened by xdm for
"Chooser" connections and sending garbage ("asdf asdf asdf\n" is
sufficient) xdm can be made to stop managing the local display,
producing the following in its error log:

>Fatal server error:
>Server is already active for display 0
>        If this server is no longer running, remove /tmp/.X0-lock
>        and start again.
>
>
>When reporting a problem related to a server crash, please send
>the full server output, not just the last messages
>
>xdm error (pid 27035): server unexpectedly died
>xdm error (pid 27035): Server for display :0 can't be started, session disabled

If there is a session open at the time then xdm will fail to offer a
login screen when it has ended.  If no session is active (the login
screen is presented) then the login screen disappears.  In either case
the problem can be corrected by killing the X server and sending a HUP
signal to xdm (which was started with -nodaemon is my case).

I am not aware of any work around.


The second problem is that the Chooser TCP socket is not closed on
exec, and thus all descendents of xdm (all X clients, programs running
in xterms, etc.) inherit a file descriptor for the Chooser socket.
While I don't have any actual exploit for this, there may be the
potential to either interfere with xdm's normal function or to
redirect a client to an untrusted/insecure host.

I am not aware of any work around.