Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Aug 1997 09:29:13 -0400 (EDT)
From:      David Holland <dholland@eecs.harvard.edu>
To:        newton@communica.com.au (Mark Newton)
Cc:        Shimon@i-Connect.Net, freebsd-security@FreeBSD.ORG
Subject:   Re: FW: Denial-of-service attack against INETD.  Redhat 4.X and othe
Message-ID:  <199708271329.JAA00911@burgundy.eecs.harvard.edu>
In-Reply-To: <9708270326.AA12076@communica.com.au> from "Mark Newton" at Aug 27, 97 12:56:26 pm

next in thread | previous in thread | raw e-mail | index | archive | help
 > What kind of weenie posts a long rambling message to CERT about a denial
 > of service issue that's documented for all to see in the manpage anyway?

Don't ask me...

 > Eh?  inetd sleeps in two places:  One of them is when a fork() fails.
 > The other is when the select() that's used to detect incoming connections
 > fails (i.e.: returns <= 0).  What has Linux done to their inetd? :-)

Nothing. :-p

I picked up the guy's "fixes", and it's a completely new version of
inetd. Since he seems to have decided it was a good idea to reindent
and reformat everything, I can't tell what he's done.

I think he misunderstood the significance of the EINTR in 

            if ((n = select(maxsock + 1, &readable, (fd_set *)0,
                (fd_set *)0, (struct timeval *)0)) <= 0) {
                    if (n < 0 && errno != EINTR)
                        syslog(LOG_WARNING, "select: %m\n");
                    sleep(1);
                    continue;
            }

However, he seems to have changed that sleep to a sleep(60). So I
don't know what he's smoking.

 >  > One other change: it used to be that if bind() fields when setting
 >  > up a socket, inetd would wait 10 minutes before trying again.  I
 >  > lowered this value to 10 seconds.
 > 
 > If bind() fails it usually indicates the kind of savage resource shortage
 > that perfectly justifies backing off for ten minutes or so.  To reduce
 > this back-off to ten seconds introduces the possibility that inetd
 > can actually contribute to Denial Of Service problems by compounding
 > existing resource shortages.

That, and the most common cause of this failure is accidentally
running two inetds at once, so there's no point in hurrying to retry.

-- 
   - David A. Holland             |    VINO project home page:
     dholland@eecs.harvard.edu    | http://www.eecs.harvard.edu/vino



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708271329.JAA00911>