While working on my free security scanner ( www.insecure.org/nmap ), I
noticed some strange behavior in Linux 2.2 kernels (including
2.2.12). Sometimes a connect() to localhost will succeed even if
there is no process listening on the port. This happens when the
ephemeral local port selected by the kernel during the connect()
happens to be the same port you are trying to connect to. In effect,
you end up connecting to yourself. Any data written to the socket
is available for reading by the same socket. This can be demonstrated
with telnet:
amy~>while(1)
while? telnet localhost 1035
while? end
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Hello, World! <--- I wrote this
Hello, World!
echo <--- and this
echo
^]
telnet>
[ Note that there will usually be many more failures than this prior to
the connect -- give it a couple of minutes. Also this will only work in
the epheremal port range ( 1024-4999 by default) ]
This can cause very strange problems when an application tries to
connect() to a crashed server process and ends up connecting with
itself rather than getting ECONNREFUSED. Many people put Socks
servers, Oracle, etc. in that port range.
A related issue is that Linux 2.2 allows you to do this sort of thing:
sd = socket(tcp)
bind(sd, port 20000)
connect(sd, port 20000)
write(sd, "stuff")
This leads to similar behavior as before and is not allowed in Linux
2.0.33 or several other operating systems I tried. You can test this out
with:
nc -p 20000 localhost 20000 # nc is Hobbit's Netcat
This latter case isn't a particularly big deal, since it is user
stupidity. But I wanted to bring it up in case these kind of
shenanigans (self-connected sockets) can cause any kernel problems.
It would be great if the first issue (bogus connect() success) could
be fixed. I looked at the code and it might require some minor
parameter restructuring. If a patch will be accepted, I would be
happy to write and test one. But I wanted to give the maintainers
first dibs since they probably have opinions on the "right" way to fix
this.
Cheers,
Fyodor
-- Fyodor 'finger pgp@pgp.insecure.org | pgp -fka' Frustrated by firewalls? Try nmap: http://www.insecure.org/nmap/ "The percentage of users running Windows NT Workstation 4.0 whose PCs stopped working more than once a month was less than half that of Windows 95 users." -- microsoft.com/NTWorkstation/Basics/Features/Reliability/
- 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/