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