lkml.org 
[lkml]   [1999]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [FIX] Re: connect() occasionally succeeds improperly to localhost port 1024-4999
On Mon, 30 Aug 1999, Craig Milo Rogers wrote:

> The first generation of Internet programs (telnet, FTP, etc.)
> connect from a transient port to a well-known port, and won't see the
> problem you described.

Right, although sometimes you telnet to higher ports for debugging and
non-root users often have to run well-known services on ports 1024+.

[cut]
> Rather than
> redesigning TCP, you could make your scanner program bind() itself to
> a port before connecting (a 1 line solution to your application, no
> kernel change needed).

It is not a 1 line solution since you need loops and variables to tackle
the case where the selected local port is unavailable. Not to mention
error checking, filling up a sockaddr_in structure, etc. It is a half
dozen line solution, and it requires an extra system call for every
connection. Further you need to change each application that might connect
to a transient port (and you cannot count on everyone using the same
transient port range). The whole point of the implicit bind() in connect
is to save applications from the trouble of picking an appropriate port.
I would like to see the kernel valid port tests ( tcp_v4_get_port(),
etc) disallow the destination port when picking a source port for a
connect().

It is worth noting that this issue does seem Linux 2.1-3 specific. I have
been unable to reproduce accidental self-connections on my 2.0.33 box and
my OpenBSD 2.3 box.

> As you suggest, the Linux socket/TCP code can be modified to
> avoid accidental self-connections. This can be done without
> interfering with intentional self-connection.

I think this would be desirable. Can anyone think of a case for allowing
these accidental self-connections?

> This involves a trivial change to
> ipv4/tcp_ipv4/tcp_v4_get_port() in linux-2.2.12 and linux-2.3.15.
> In the rover loop, before the "break;", add:
>
> if (sk->dport == rover) goto next;

I don't believe it is quite this simple, since sk->dport isn't initialized
until after the tcp_v4_get_port call. inet_stream_connect() calls
inet_autobind() early on. The latter immediately calls tcp_v4_get_port()
for this type of socket. Perhaps sk->dport could be initialized at the
beginning of inet_stream_connect()? I am not familiar enough with the
kernel to judge the side effects of such a move.

Thanks for your comments,
Fyodor


--
Fyodor 'finger pgp@pgp.insecure.org | pgp -fka'
Frustrated by firewalls? Try nmap: http://www.insecure.org/nmap/
In a free and open marketplace, it would be surprising to have such an
obviously flawed standard generate much enthusiasm outside of the criminal
community. --Mitch Stone on Microsoft ActiveX




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.034 / U:12.688 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site