httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: suexec concerns
Date Fri, 03 Jan 1997 22:38:34 GMT
On Fri, 3 Jan 1997, Randy Terbush wrote:

> > On Fri, 3 Jan 1997, Randy Terbush wrote:
> > Heck, take the typical silly system with lots of bin owned binaries.  What
> > is bin's home directory on your system?  "/"?  "/bin"?  "/usr/bin"?  Cool,
> > as HTTPD_USER do:
> > 
> > 	cd /bin
> > 	/path/to/suexec \~bin bin sh
> > 
> > bin looses.
> Not unless you have compiled the suexec wrapper with /bin as the 
> DOCUMENT_ROOT.  DOCUMENT_ROOT is the only thing that makes this
> halfway acceptable. The programs being executed at least need to
> reside in the webspace to be at risk.

NO!  The above works here, I tested it using the following suexec.h:

#define HTTPD_USER "marcs"
#define LOG_EXEC "/usr/local/etc/httpd/logs/cgi.log" /* Need me? */
#define DOC_ROOT "/usr/local/etc/httpd/htdocs"
#define SAFE_PATH "/usr/local/bin:/usr/bin:/bin"

(HTTPD_USER set to marcs to make testing easier, with the assumption that
the HTTPD_USER account is compromised.)

On my system:

bin:*:3:7:Binaries Commands and Source,,,:/:/nonexistent

suexec lets you execute programs from under a user's home directory.
bin's home directory is "/" on my FreeBSD system.  On an AIX system I
looked at, it is /bin, /usr/bin on a Solaris system, /bin on a
SunOS one.  You put a shell under someone's home directory, therefore
suexec can run it.  It does _NOT_ have to be in web space; hence
the suggestion to make suexec go through the same process to see
if something is a CGI that the main server would.

> > > > So I can see two choices.  Either we make it so the HTTPD_USER can't
> > > > be compromised easily (which can certainly be done with the right
> > > > config file without source changes, but there will be many people
> > > > who don't realize the implications of using suexec while letting
> > > > other things run as HTTPD_USER) or we make it so that suexec doesn't
> > > > trust what it is told.  This would include:
> > > > 
> > > > 	- only passing certain environment variables from suexec to
> > > > 	  the process being run.
> > > 
> > > Ughh. Could be a support nightmare.
> > 
> > A very big one.  External config file.  Easy to modify.  Documented well.
> > There aren't _that_ many variables which need to be passed.
> The problem though is that what environment variables get past is _very_
> configurable. With 100's or even 1000's of webservers to admin, there
> will be a continuous stream of experts that have yet another variable
> to add to the list.  Am I being a cynic? :)

I don't think that most people use anything other than the basic
variables like REMOTE_HOST that the server sets.  The only other ones
are ones that are set by the admin before the server is started, no?  

> There are probably some specific things that should _not_ be passed.
> That might be easier to implement than the former. Any suggestions?
> We recently added code to nuke PATH. Probably ought to do the same

I don't think LD_LIBRARY_PATH is necessary, because libc should nuke
it since suexec is setuid.  There may be some evil libc's that just
ignore it instead of killing it, so it wouldn't hurt.  A whole
whack of things like ENV and IFS should be killed.  If we want to
nuke based on known bad variables I can think up a list of suggestions

> > The other thing I wouldn't mind would be the equivalent of crontab's allow
> > and deny files, but that's a feature not a bugfix and is for the future.
> Could be useful. As you point out though, this is nearly an all or
> nothing feature. If _everyone_ is not being handled by the wrapper,
> there are some holes.

I would argue there are more than "some" holes.

This would give you the ability to stop people from running _any_
CGIs, not just to stop suexec from being used for them.  ie. make
all CGIs use suexec, then only allow certain ones to get past it.

View raw message