httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <>
Subject Re: suexec concerns
Date Fri, 03 Jan 1997 22:22:42 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. 

Joe has copied a shell binary into his webspace.  Not good.

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

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

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

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

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

Or user's home directory.  I'll make that more clear.

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

Thanks. I'll try to review it again as well.  Good to have some eyes other
than the author's on it.

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