httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject suexec concerns
Date Fri, 03 Jan 1997 20:57:25 GMT
I have some concerns about suexec; this post is somewhat long, but I
want to try to comment on some of the issues and make sure everyone
realizes the problems.  

All my comments are based on the assumption that the userid defined for
HTTPD_USER in suexec.h can be compromised.  Is that a valid assumption?
Not always.  However, consider that:

	- without suexec, if someone runs any CGIs, they can compromise
	  the HTTPD_USER account.  Some people will have a backdoor
	  into that account lying around even if things are changed so
	  they can't any more.
	- unless the site is setup to use suexec for _all_ CGIs,
	  HTTPD_USER can be compromised by the CGIs that don't use
	  suexec.  If you are using suexec for virtual domains, then
	  it would seem that any CGIs run from the main domains
	  (unless they are ~user ones) have to run as HTTPD_USER.

On the assumption that the HTTPD_USER account is compromised, it is
too darn easy to compromise other accounts.  Say user "joe" has his
own copy of a shell in ~joe/bin/sh, and he makes his bin directory
world readable.

As HTTPD_USER:

	cd ~joe/bin
	/path/to/suexec \~joe joegroup sh

Cool, I have a shell as joe.  I don't think this is safe.  Even if there
isn't anything as obviously exploitable as vi, there are lots of other
holes to exploit.  Anyone have any world readable shell scripts
around? Easy to use them, especially because suexec passes the
environment unmodified; $ENV anyone?  

cgiwrap doesn't look much better (hmm... also looks like there may
be a couple of bugs in it, possibly security holes), but cgiwrap
is far less likely to be setup so that people can compromise the
HTTPD_USER account as easily.

The solution?  Good question.  

To run scripts as a user, the web server needs some way to switch to a
pseudo-arbitrary user.  We don't want that in the web server itself,
since then it needs to run as root under nearly every unix, so we need
an external process running as root to do this.  Since we don't want
anyone to be able to run programs as an arbitrary user, we need to
limit it so only the web server can talk to the program running as
root.

Currently, suexec is doing that by assuming that anything running as
HTTPD_USER is the web server and can be trusted.  That is the problem;
I think there are currently too many other ways to compromise the
HTTPD_USER account.  There are lots of fancy schemes you can dream up
like public/private key authentication between the server and suexec,
but they don't solve much because you have to assume that anyone who
compromises HTTPD_USER compromises all of that.

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.
	- having suexec through the same process as the main server
	  does to decide if something can be executed as a CGI or not.

I'm still thinking about solutions, but I think this is a real
concern.  At the _VERY_ least this should be explained in LARGE short
words in the documentation.



Mime
View raw message