[5724] in bugtraq
Re: Linux inetd..
daemon@ATHENA.MIT.EDU (Alan Cox)
Tue Dec 2 22:36:25 1997
Date: Tue, 2 Dec 1997 20:50:01 +0000
Reply-To: Alan Cox <alan@LXORGUK.UKUU.ORG.UK>
From: Alan Cox <alan@LXORGUK.UKUU.ORG.UK>
X-To: aleph1@DFW.NET
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <Pine.SUN.3.94.971202003514.19463B-100000@dfw.dfw.net> from
"Aleph One" at Dec 2, 97 00:50:26 am
> Now you may be wondering why does a write to the socket returned by
> accept() generates a SIGPIPE. This bring us to the second issue. It seems
> that at least under Linux 2.0.X accept will return a socket in the
> received queue if it is not in the SYN_SENT or SYN_RECV state, even when
> it has not gone through the ESTABLISHED state.
>
> By doing a stealth scan on the port the socket goes from the SYN_RECV
> state to the CLOSED state. When you try to read from such a socket you
> get a SIGPIPE. The sematics of Linux's accept seems to be non-standard. I
> wonder what else breaks by not handling SIGPIPE.
On that issue you are a little astray. Linux merely made the window for
the inetd problem a bit larger. You can hit a box betwen the accept
returning towards user space and the write() with a seperate RST frame
regardless of what accept returns. If generic BSD has this missing
SIGPIPE I venture to say that if you can hit the precise boundary needed
you can bring down inetd there too.
ie
SYN/ SYN-RECV/ ACK
accept()
RST
write()
SIGPIPE
Alan
