Bug#251037: Strange xdmcp behavior, maybe a trojan horse?
Branden Robinson wrote:
Hello,
That's probably a bug. It may have something to do with:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1985
*That* bug has been open for over 8 years. :(
[and from another mail]:
> Does it sound like this one?:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=4757
First thing first, in my opinion xdm works perfectly well in all those
situations. I think I understand now *why* it behaves this way. And what's
worst, it can be assumed as the right behavior. :-(
As far as I can understand the situation, the problem is caused by Xserver
and RFC1122, where "weak end host" is defined. During connection setup,
Xserver sends its IP address in a XDMCP packet to a xdm process on a remote
host. But which IP should be sent by a multihomed Xserver? The logic says,
the IP of the interface which leads to a remote xdm. But in a consequence of
RFC1122, all host's IPs are local on every interface (for incomming packets,
of course). One can easily check it's true, just traceroute to a box with
more than one interface:
fback@obora:~$ traceroute 192.168.1.254
traceroute to 192.168.1.254 (192.168.1.254), 30 hops max, 38 byte packets
1 chlew-wifi.home.fback.net (192.168.1.254) 2.649 ms 1.878 ms 1.961 ms
fback@obora:~$ traceroute 192.168.0.1
traceroute to 192.168.0.1 (192.168.0.1), 30 hops max, 38 byte packets
1 192.168.0.1 (192.168.0.1) 2.221 ms 2.474 ms 1.974 ms
fback@obora:~$ traceroute chlew
traceroute to chlew.home.fback.net (80.53.236.154), 30 hops max, 38 byte packets
1 chlew.home.fback.net (80.53.236.154) 2.232 ms 1.744 ms 2.751 ms
I can even add some public IP to a chlew's loopback interface and:
chlew:~# ifconfig lo:1 204.255.235.118 netmask 255.255.255.255 broadcast
204.255.235.118
fback@obora:~$ traceroute 204.255.235.118
traceroute to 204.255.235.118 (204.255.235.118), 30 hops max, 38 byte packets
1 204.255.235.118 (204.255.235.118) 2.216 ms 2.327 ms 2.360 ms
So Xserver takes all the local IPs and sends them to a remote xdm process,
allowing him to choose the best. When it's in the same subnet, it will
choose local address (and that's why it worked for me within the same
subnet), but what when all IPs are non-local? It will take the first one and
will try to connect to it.
Everything is OK according to RFCs. But on the other hand, loopback is only
a local interface, which never sends packets to a network. So in my opinion,
Xserver should never advertise its loopbacks. As far as I checked, it
doesn't send 127.0.0.1, except the situation when connecting to it
explicitely. I think it should never send *any* IP assigned to a loopback
[sub]interface(s). Unfortunately, I'm not sure there's easy way to check, if
an address is assigned to a loopback.
Sending loopback would make sense only in a situation, when the Xserver is
running on a multihomed box, with 2 (or more) interfaces which are available
through different paths. But who runs Xserver on a BGP router? ;-)
I guess, that a scenario in #4757 was as follow:
First interface up was eth0, possibly with a private IP. Second interface up
was ppp0 (so Xserver advertised private IP as the first one, and public as
the second). It caused remote xdm connects to an unavailable IP.
Would configuring interfaces in some explicit order solve my (and all other)
problems? I'll try this next week.
Regards,
BO
PS. Sorry for my english. :(
Reply to: