httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: suexec concerns
Date Fri, 03 Jan 1997 21:56:55 GMT
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,

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

View raw message