Re: suexec concerns

[Randy Terbush <ra...@zyzzyva.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.

Re: suexec concerns

[Marc Slemko <ma...@znep.com>]

On Fri, 3 Jan 1997, Marc Slemko wrote:

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

I forgot all about mentioning the reason I originally thought this may be
a good idea: so it can, by default, exclude all the system ids we can
think of by putting them in a default deny file. 

The alternative, of course, is simply all uids under 100 or some arbitrary
number which would get many of them.

That is, of course, just a bandaid not a fix.

Re: suexec concerns

[Marc Slemko <ma...@znep.com>]

On Fri, 3 Jan 1997, Randy Terbush wrote:

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

But joe has done nothing wrong.  If people want to be morons and write
CGIs that are insecure, fine; that is a risk, but a known and easily
understood risk.  But joe didn't write a CGI.  Heck, he may not even have
a web page.  He just has some executable file that is world readable.  In
fact, I would say that important accounts (eg. admins) are more likely
than most to have such things.  Take a look around on some systems and see
just how many accounts you find with a world readable executable (or shell
script; if the shell is Bourne like and listens to $ENV, it is evey
easier).  I think that on most systems there are a lot. 

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.

Breaking basic assumptions like "a read only file is a read only file and
won't hurt anyone unless there is something bad in it" is not a good thing
to do. 

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

It could be a deterrent, but I would have to look at it more to be
convinced that it couldn't be compromised by someone who compromised the
user the web server runs as.  I think whatever you do, it would be partly
operating system dependent, ie. related to how the OS deals with things
like debuggers with processes that have changed their uid. 

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

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

The step by step listing of the "Security Model of suEXEC" is a very good
thing, but step 4 isn't accurate when you consider ~user directories.

The warning there is perhaps a bit forceful; "don't do this because you
are a moron and can't understand it" is more often than not true but
people won't listen to that.  I'm not sure the web page is clear enough
about the reasons for the complexity.  If I get time I will try to offer
some more specific suggestions.

...and the document certainly doesn't make the consequences clear for poor
souls who don't care about web pages but have a world readable executable.