httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: suexec concerns
Date Fri, 03 Jan 1997 23:15:51 GMT
On Fri, 3 Jan 1997, Randy Terbush wrote:

> 
> > 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.
> 
> This is probably best solved by forcing the execution of ~user cgi
> to reside under a compiled in ~/public_html/cgi-bin/. We've gone back
> and forth on this, but seems prudent in light of the above.

That is one possibility that should solve many of the most serious
security problems as far as I can see.  There is the "it's ugly" argument,
but ugly better than dangerous.

> 
> I must point out that I don't allow _any_ ~user CGI on my systems,
> so I have not given the ~user feature of suexec quite enough
> scrutiny.
> 
> As you pointed out, this does not solve the issue of copies of things
> like sh in the user webspace.

Or someone with an ill-thought link designed to make their life easier. 
>From under docroot, 'ln -s / foo' will open a hole, although it doesn't
allow you to get anything except the "User" defined uid for that space. 
Note that this will do the same thing regardless of if symlinks are
allowed in the server config.

> 
> > > > > > 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?  
> 
> mod_env?

>From the docs:
                       
   This module allows Apache's CGI and SSI environment to inherit
   environment variables from the shell which invoked the httpd process.
   CERN web-servers are able to do this, so this module is especially
   useful to web-admins who wish to migrate from CERN to Apache without
   rewriting all their scripts

(hmm... UnsetEnv doesn't seem to be documented.  Any reason, or just an
accident?) 

If you wanted, you could have suexec read the config file and allow
variables set in PassEnv or SetEnv, since from what I see those are the
only ones that are allowed through from the parent shell; normally none
are. 

Ok, I'm slighly wrong here; many headers will be passed through from the
request with HTTP_ prefixed.  See add_common_vars in util_script.c for
details. 

So, if you pass:
	- anything in PassEnv or SetEnv through if mod_env is in use
	- HTTP_*
	- the known ones that apache sets itself

and deny everything else, you shouldn't be blocking anything legitimate.



Mime
View raw message