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, 10.0.0.1 and
asked it to connect to xdm process at, say, 192.168.1.1 and out of
sudden, it reported an error saying, it cannot use display at
194.237.107.43!
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 127.0.0.1/8. :-(
Regards,
BO
Reply to: