X-RDate: Thu, 18 Dec 1997 09:55:27 +0500 (ESK)
Date: Tue, 16 Dec 1997 13:15:44 +0300
From: Vadim Kolontsov <[email protected]>
To: [email protected]Subject: [[email protected]: Re: Linux inetd..]
Hi,
this message was posted at Dec 3, but wasn't appeared in bugtraq. Because
it answers some recent questions (like "I believe it's linux kernel bug"),
I am sending it again
Best regards,
V.
-----Forwarded message from Vadim Kolontsov <[email protected]>-----
From: Vadim Kolontsov <[email protected]>
To: moOd <[email protected]>
Cc: [email protected]Subject: Re: Linux inetd..
Hi,
On Sun, Nov 30, 1997 at 02:19:50PM +0100, moOd wrote:
> I've found that inetd on (*atleast*) Debian distribution of LiNUX crashes
> when port 13 (daytime) / port 37 (time) is "half-open scanned"..
The workaround for inetd - put it in "fork() after accept()" mode
(some option in command line). Another workaround - put your router
in "ip established" mode (router will pass session only after
connection will be established)
I can explain a problem (sorry if all things are already well known by world)
The problem caused by an implementation of Linux kernel - accept() returns
socket after getting first SYN (for example, BSD returns socket only after
3-way handshake). If your program uses getpeername() or getsockname()
right after the accept(), it will detect the situation when socket
is not valid (because connection was cancelled by RST), but in any
other case it has big chances to die due SIGPIPE. So well-written
programs aren't affected.
I've found this behaviour in fall of 1996, then I notified linux-security and
has an e-mail discussion with Eric Schenk (linux IPv4 maintainer) somewhere
in May'97. I suggested to correct linux kernel behaviour, but he said that
it's not clear that accept() must return socket _only after_ 3-way handshake.
If someone will be interested, I can contact him to ask permission to
make our email discussion available online.
This bug can also affect early sendmail versions (can't remember exact
version, something around 8.7.*), see an example:
---------------------------- cut here -------------------------------
11:37:48>telnet x.y.z 25
Trying 1.2.3.4...
Connected to x.y.z.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
11:37:48>~vadim/C/inkill -p 25 x.y.z 25
Source host: 10.11.12.13
Destination host: 1.2.3.4
Destination port: 25
Sending SYN packet... Done
Sending RST packet... Done
11:37:48>telnet x.y.z 25
Trying 1.2.3.4...
telnet: Unable to connect to remote host: Connection refused
11:37:49>telnet x.y.z 25
Trying 1.2.3.4...
telnet: Unable to connect to remote host: Connection refused
11:37:49>telnet x.y.z 25
Trying 1.2.3.4...
Connected to hades.sprintlink.co.za.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
---------------------------- cut here -------------------------------
(notify a timemarks; IP/domains are changed)
This bug affects ssh, but ssh does fork() right after accept(), so
only child dies.
Quoting me (28 May 1997):
VK> So (afaik) almost all programs on linux, which listens for network
VK> connections, can be crashed by sending SYN,RST... except the programs
VK> that makes ALL checks correctly. (getsockname() will fail on such
VK> descriptors, for example). But sshd, inetd etc - doesn't. so
VK> we have to notify the authors and correct almost ALL server-applications
VK> in linux.
And last things:
1) I don't know any TCP/IP stack that has such behaviour except
linux.
2) I'm not sure about modern linux versions, I've checked only
some of them like 2.0.x early in 1997.
Best regards,
V.
--
Vadim Kolontsov
Tver Internet Center NOC
phone: +7-(0822)-365743
-----End of forwarded message-----
