[5730] in bugtraq
Re: Linux inetd..
daemon@ATHENA.MIT.EDU (Darren Reed)
Wed Dec 3 02:43:15 1997
Date: Wed, 3 Dec 1997 16:39:03 +1100
Reply-To: Darren Reed <avalon@COOMBS.ANU.EDU.AU>
From: Darren Reed <avalon@COOMBS.ANU.EDU.AU>
X-To: alan@LXORGUK.UKUU.ORG.UK
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <m0xczGb-0005FsC@lightning.swansea.linux.org.uk> from "Alan Cox"
at Dec 2, 97 08:50:01 pm
In some mail from Alan Cox, sie said:
>
> > 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.
I don't see that being a problem for the BSD inetd as it fork()s before the
write and the process which receives the SIGPIPE is a child of inetd, not
the master (so to speak). I would have thought the linux one would behave
the same.
Darren
