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.
-- Paul H. Hargrove All material not otherwise attributed hargrove@sccm.stanford.edu is the opinion of the author or a typo.