Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
Xdm/chooser seurity problemsPaul H. Hargrove (hargroveSCCM.STANFORD.EDU)
Fri, 8 Aug 1997 16:58:22 -0700
- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Phillip R. Jaenke: "Re: CPSR #8: identd Denial of Service"
- Previous message: dynamoIME.NET: "popper and qpopper let you read email from other pop clients"
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. -- Paul H. Hargrove All material not otherwise attributed hargrovesccm.stanford.edu is the opinion of the author or a typo.