From owner-freebsd-hackers  Tue Jan 16 19:35:35 2001
Delivered-To: freebsd-hackers@freebsd.org
Received: from manor.msen.com (manor.msen.com [148.59.4.66])
	by hub.freebsd.org (Postfix) with ESMTP id B65EA37B402
	for <hackers@FreeBSD.ORG>; Tue, 16 Jan 2001 19:35:16 -0800 (PST)
Received: from manor.msen.com (wayne@localhost [127.0.0.1])
	by manor.msen.com (8.9.3/8.9.3) with ESMTP id WAA18537
	for <hackers@FreeBSD.ORG>; Tue, 16 Jan 2001 22:35:10 -0500 (EST)
	(envelope-from wayne@manor.msen.com)
Message-Id: <200101170335.WAA18537@manor.msen.com>
To: hackers@FreeBSD.ORG
Subject: Protections on inetd (and /sbin/* /usr/sbin/* in general)
Date: Tue, 16 Jan 2001 22:35:10 -0500
From: "Michael R. Wayne" <wayne@staff.msen.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


Background:
   We recently had a customer's web site suffer an attempted exploit
   via one of their cgi scripts.  The attempted exploit involved
   writing a file into /tmp, then invoking inetd with that file to
   get a root shell on a non-standard port.  While the exploit
   failed, they were able to write the file as user nobody and
   invoke inetd.  There is not much we can do about that as long
   as we permit customers to use their own cgi scripts, which is 
   a requirement with this type of account.

Issue:
   The exploit managed to start inetd, camped on the specified port
   but inetd, properly, failed as soon as it tried to start the
   service (running as user nobody makes doing setuids difficult :-)
   Tests by our staff from the command line indicate that any user
   is able to start inetd with a local config file associating a
   service with a non standard port.  It doesn't WORK but it does
   attach to the port.  Leading to some DOS possibilities, albiet
   not very interesting ones.

Recommendation:
   A number of the executables located in /sbin and /usr/sbin are
   never going to be invoked for any legitimate use by anyone other
   than the superuser.  In particular, servers such as portmap and
   inetd run by non-root users are unlikely to do what was intended.
   It seems a prudent measure to simply not set execute permission
   by "other" on such programs during the install, giving the user
   a handy "Permission denied" message when such an attempt is made.

   For those reading quickly, I am NOT recommending removing execute
   permission on ALL of /sbin/* and /usr/sbin/*, only on programs
   such as "portmap", "inetd", "lpd", "syslogd", "halt", "reboot"
   and others which perform no useful function to normal users.
   /sbin/init already enforces this condition, how about expanding it?

/\/\ \/\/


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