Message-Id: <199701032122.PAA10377@sierra.zyzzyva.com>
To: new-httpd@hyperreal.com
Subject: Re: suexec concerns 
In-reply-to: marcs's message of Fri, 03 Jan 1997 13:57:25 -0700.
         <Pine.BSF.3.95.970103125030.7163D-100000@alive.ampr.ab.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 03 Jan 1997 15:22:14 -0600
From: Randy Terbush <randy@zyzzyva.com>
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

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

This is the assumption that we made as we tried to find a solution
that was "safe".

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

Joe loses.  Seriously though, there are an infinite number of other
things that Joe can do to risk his own account security. As Joe,
I'm more comfortable knowing that 'jim' can't run a CGI as HTTPD_USER
and nuke the entire server.

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

Actually, there was some discussion of a mechanism that would have
the webserver generate some random key at startup which it would
pass to the wrapper to confirm that the wrapper was in fact being
called by the server. RST and Ben kicked around some ideas about
this, and I think I have stashed somewhere the beginnings of some
code from RST.

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

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

You might glance at http://www.apache.org/docs/suexec.html if you haven't
already. I attempted to make these issues clear, but may not have
succeeded.

Thanks much for your comments Marc.