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

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

Branden Robinson wrote:

I am having some difficulty understanding your report.

First, why did you file this bug against "xserver-common"?
I meant "xserver-xfree86", but... but...

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

"[...] A broadcast domain is the set of all devices that will receive broadcast frames originating from any device within the set. Broadcast domains are typically bounded by routers because routers do not forward broadcast frames. [...]"

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.
Yes, but both my Xserver and xdm process runs at an other ip than reported.

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?

That confused me either! %-) I started Xserver at, say, and asked it to connect to xdm process at, say, and out of sudden, it reported an error saying, it cannot use display at!

I don't know where the "Connection" IP addresses come from.
I didn't know either, but I've discovered it later, they were assigned to lo:1...lo:5 interfaces. But why the hell it's sending its loopbacks as address it's listening for a remote connection??

Did you know that Debian X servers have TCP listening disabled by
default as a security measure?
Sure, but it's not the case.

[1] http://bugs.debian.org/250919
I'm writing this from not-so-clean testing with kde started by kdm, with custom compiled 2.6.5 kernel with grsec patch applied. It works without any problems.

Anyway, now I can connect to a remote xdm, even outside a broadcast domain, but only with default lo interface set to :-(


Reply to: