Can you expand on that a little? I first thought that it was possible
to get this pathology to happen on a multi-homed host by using two
different interfaces as the source and destination, but haven't yet
been able to exploit it. (You'd expect that it would work on single-homed
hosts too, with a source address of 127.0.0.1, but I can't get that to
cause trouble either).
It's not possible to do a self-connect using two different interfaces,
since if you bind to an interface then you also have to connect to that
interface or it's not a self-connect, so I'm not sure what you mean by
locally running a program that connects a TCP socket to itself.
Assuming that you meant locally running something like land.c which
sends a packet forged from one interface destined for another, I've
tried that. On a host which is vulnerable to the "standard" attack, I
see the following packets when I forge a SYN from one interface address
to the other:
20:21:32.187983 InterfaceA.telnet > InterfaceB.telnet: S 1:1(0) win 1024 (ttl 255, id 69)
20:21:32.188092 InterfaceB.telnet > InterfaceA.telnet: S 95950695:95950695(0) ack 2 win 16384 <mss 16344> (DF) (ttl 64, id 409)
20:21:32.188113 InterfaceA.telnet > InterfaceB.telnet: R 2:2(0) win 16384 (ttl 64, id 410)
Bill