Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Aug 2000 20:25:21 +0200
From:      sthaug@nethelp.no
To:        silby@silby.com
Cc:        kelleyry@bc.edu, razor@ldc.ro, freebsd-security@FreeBSD.ORG
Subject:   RE: xinetd versus inetd
Message-ID:  <28279.966363921@verdi.nethelp.no>
In-Reply-To: Your message of "Tue, 15 Aug 2000 11:15:25 -0500 (CDT)"
References:  <Pine.BSF.4.21.0008151111010.88715-100000@achilles.silby.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> I used to run tcpserver, but soon realized that xinetd could perform all
> the same important functions, and was much easier to configure.
> 
> I don't think any modern inetd is as susceptible to resource exhaustion
> attacks as the tcpserver page will lead you to believe, but running xinetd
> does seem wise, as you can tune the various resource limits quite exactly.

But do you trust xinetd? Seems it's time to repost the following News
article from Marcus Ranum, dating back to 1993. Still relevant, I think.

Note: I have no personal experience with xinetd.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no
----------------------------------------------------------------------
From: mjr@tis.com (Marcus J. Ranum)
Subject: Re: Frigging inetd!!!!
Date: 26 Oct 1993 19:07:53 GMT

[I added comp.security.unix to the distribution and dropped the
gopher group, since this is really a security rant, and part of
an ongoing rant from comp.security.unix]

>	Why not just get a copy of the source for inetd and rebuild it
>for your system?  Also, there is a new program called xinetd, which
>is supposed to be an augmented inetd that has built in security.  I've
>got the source code, but I have not had much of a chance to play with
>it yet.

	Here I must insert my mandatory rant about "augmentation"
"features" and "security."

	Xinetd has (presumably) a huge number of features. It's also
a relatively huge piece of code. Compare it to the BSD inetd sources:

Program                                     Modules   Lines of Code
-------                                     -------   -------------
inetd, from BSD Net-2                          1          964
xinetd, minus support libraries               36        11801

	For a security critical application like inetd, the last
thing you want is security at the price of 12 times as much code.
Large programs that do security critical things (sendmail, xinetd,
wuarchive-ftpd, Xterm) are traditionally a snakepit of security
holes.

	The idea of "built in security" is contrary to most formal
security practices. The security critical policy sections should
be clearly isolated from the rest of the code that does bookkeeping
or whatever else.

	I enclose below a version of inetd that's 80 lines of code.
The security critical section is clearly visible. More importantly,
the implementation is small enough that when I showed a copy to a
friend, he instantly spotted a bug. It's a lot easier to spot a
bug in a 1 page program, than in an 11,801 line program that is
36+ files in 2 directories. Also, this version of inetd is not
vulnerable to attacks on inetd.conf since it doesn't use one,
and doesn't have any argument limitations on the invoked programs.
It doesn't support UDP services, but then, from a security standpoint,
UDP services make me all nervous anyhow. Note, too, that the code
has only one comment. It's simple enough that it needs no comments.

mjr.
------------------------------
#include	<sys/types.h>
#include	<sys/signal.h>
#include	<sys/socket.h>
#include	<netinet/in.h>
#include	<syslog.h>
#include	<netdb.h>

reap()
{
	int	s;
	while(wait(&s) != -1);
}

main(ac,av)
int	ac;
char	*av[];
{
	struct	sockaddr_in	mya;
	struct	servent		*sp;
	fd_set			muf;
	int			myfd, new, x, maxfd = getdtablesize();

	openlog("inetd",LOG_PID,LOG_DAEMON);
	if(ac < 3) {
		syslog(LOG_ERR,"usage: %s serviceport command [args]",av[0]);
		exit(1);
	}
	signal(SIGCLD,reap);
	if((myfd = socket(AF_INET,SOCK_STREAM,0)) < 0) {
		syslog(LOG_ERR,"socket : %m");
		exit(1);
	}
	mya.sin_family = AF_INET;
	bzero(&mya.sin_addr,sizeof(mya.sin_addr));
	if((sp = getservbyname(av[1],"tcp")) == (struct servent *)0) {
		if(atoi(av[1]) <= 0) {
			syslog(LOG_ERR,"Cannot interpret %s as service",av[1]);
			exit(1);
		}
		mya.sin_port = htons(atoi(av[1]));
	} else
		mya.sin_port = sp->s_port;

	if(bind(myfd,(struct sockaddr *)&mya,sizeof(mya))) {
		syslog(LOG_ERR,"bind: %m");
		exit(1);
	}

	/* END SECURITY CRITICAL CODE */
	/* setuid(4); */

	if(listen(myfd,1) < 0) {
		perror("listen");
		exit(1);
	}

loop:	FD_ZERO(&muf);
	FD_SET(myfd,&muf);
	if(select(myfd + 1,&muf,0,0,0) != 1 || !FD_ISSET(myfd,&muf))
		goto loop;
	if((new = accept(myfd,0,0)) < 0)
		goto loop;
	if(fork() == 0) {
		for(x = 2; x < maxfd; x++)
			if(x != new)
				close(x);
		for(x = 0; x < NSIG; x++)
			signal(x,SIG_DFL);
		dup2(new,0);
		close(new);
		dup2(0,1);
		dup2(0,2);
		execv(av[2],av + 2);
		syslog(LOG_ERR,"exec %s: %m",av[2]);
		exit(1);
	}
	close(new);
	goto loop;
}


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




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