[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#251037: Strange xdmcp behavior, maybe a trojan horse?

tag 251037 + moreinfo

On Wed, May 26, 2004 at 04:40:26PM +0200, Bartłomiej Ochman wrote:
> Package: xserver-common
> Version: 4.3.0.dfsg.1-1

I am having some difficulty understanding your report.

First, why did you file this bug against "xserver-common"?  What file in
"xserver-common" do you believe to be at fault for the behavior you are

> I was unable to connect to a remote xdm, but only when it is outside a 
> broadcast domain.

Forgive my ignorance, but what is a "broadcast domain"?

> X crashes with a message:
> Fatal server error:
> XDMCP fatal error: Session failed Session XXXXXXXX failed for display 
> 194-237-107-43.customer.telia.com:9: cannot open display.

That doesn't look like a "crash" to me.  It looks to me like you
launched a local X server, asking a remove XDM process to manage it, but
the remote XDM rejected your connection, so the X server exited.

(The X server is the only application I know of where any means of
exiting whatsoever, even normally, is characterized as a "crash".[1]

$ true
$ echo $?

Oh my God, "true" crashed!)

> I have nothing in common with this IP,

You confuse me further.  Why is an X server on your local machine trying
to connect via XDMCP to a remote machine, if you're not the person
instructing it to do so?

Do you have a guest on your machine?

> so after further quick tcpdump, I've discovered, that the negotiation
> is as follow:

Looks normal, apart from the censorship of the IP addresses.

> and here comes suspected packet:
> with a connection field set to:
> 	Version: 1
> 	Opcode: Request (0x0007)
> 	Message length: 121
> 	Display number: 9
> 	Connections (6)
> 	 Connection 1:
> 	 Connection 2:
> 	 Connection 3:
> 	 [...]
> then a normal XDMCP Accept UDP packet.

I'm not deeply familiar with XDMCP but it looks like the remove XDMCP
server is telling you it is available to manage your session.

I don't know where the "Connection" IP addresses come from.

> The other side, of course, tries to connect to, 
> and it, of course, fails.

Whose IP is that ("")?  If nothing is listening on that
host on port 6009 (which what most X servers would run display :9 on),
then I'm not surprised that it fails.

Did you know that Debian X servers have TCP listening disabled by
default as a security measure?

> Those six addresses are always the same, no matter which non-local 
> server I try to connect to.
> I'm 99% sure this machine is not compromised, md5sum of /usr/bin/X11/X 
> is the same on every testing I'm able to check, and it's:
> 4f6c8f12266c7424a9125c259af41a39  /usr/X11R6/bin/X
> I have a laptop with 4.3.0-7 version of xserver-common and it behaves as 
>  expected.

There is not much I can do about your report without much more

[1] http://bugs.debian.org/250919

G. Branden Robinson                |    You should try building some of the
Debian GNU/Linux                   |    stuff in main that is
branden@debian.org                 |    modern...turning on -Wall is like
http://people.debian.org/~branden/ |    turning on the pain. -- James Troup

Attachment: signature.asc
Description: Digital signature

Reply to: