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 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
> for LD_LIBRARY_PATH.

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
later.

> > 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.



Mime
View raw message