httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <ra...@zyzzyva.com>
Subject Re: suexec concerns
Date Fri, 03 Jan 1997 23:33:44 GMT
> On Fri, 3 Jan 1997, Randy Terbush wrote:
> 
> > 
> > > suexec lets you execute programs from under a user's home directory.
> > > bin's home directory is "/" on my FreeBSD system.  On an AIX system I
> > > looked at, it is /bin, /usr/bin on a Solaris system, /bin on a
> > > SunOS one.  You put a shell under someone's home directory, therefore
> > > suexec can run it.  It does _NOT_ have to be in web space; hence
> > > the suggestion to make suexec go through the same process to see
> > > if something is a CGI that the main server would.
> > 
> > This is probably best solved by forcing the execution of ~user cgi
> > to reside under a compiled in ~/public_html/cgi-bin/. We've gone back
> > and forth on this, but seems prudent in light of the above.
> 
> That is one possibility that should solve many of the most serious
> security problems as far as I can see.  There is the "it's ugly" argument,
> but ugly better than dangerous.

I agree with the "it's ugly" argument, but argueably necessary.
If people want to hack this out of their own version of the wrapper,
fine by me. 

> > I must point out that I don't allow _any_ ~user CGI on my systems,
> > so I have not given the ~user feature of suexec quite enough
> > scrutiny.
> > 
> > As you pointed out, this does not solve the issue of copies of things
> > like sh in the user webspace.
> 
> Or someone with an ill-thought link designed to make their life easier. 
> >From under docroot, 'ln -s / foo' will open a hole, although it doesn't
> allow you to get anything except the "User" defined uid for that space. 
> Note that this will do the same thing regardless of if symlinks are
> allowed in the server config.

Will it?  The docroot check should nuke this since getcwd should give
us the absolute path. Did I miss something? I probably haven't prefected
my deviant thought pattern to your level. :)

> > mod_env?
> 
> >From the docs:
>                        
>    This module allows Apache's CGI and SSI environment to inherit
>    environment variables from the shell which invoked the httpd process.
>    CERN web-servers are able to do this, so this module is especially
>    useful to web-admins who wish to migrate from CERN to Apache without
>    rewriting all their scripts
> 
> (hmm... UnsetEnv doesn't seem to be documented.  Any reason, or just an
> accident?) 
> 
> If you wanted, you could have suexec read the config file and allow
> variables set in PassEnv or SetEnv, since from what I see those are the
> only ones that are allowed through from the parent shell; normally none
> are. 

Yow. I'd rather not add any more overhead to the CGI exec() process than
needed. Debatable...

Perhaps the known ones and HTTP_* would be most efficient. This would
probably be acceptable for our distributed wrapper. If an admin wants
a bigger hole, he/she could create it for themselves.

I'll see if I can get some time to apply the following changes this weekend:

* tack user-cgi directory onto the ~user path.
* disallow execution by UID < 100
* limit the environment variables passed by suexec.

> So, if you pass:
> 	- anything in PassEnv or SetEnv through if mod_env is in use
> 	- HTTP_*
> 	- the known ones that apache sets itself
> 
> and deny everything else, you shouldn't be blocking anything legitimate.

Stupid question here, but shouldn't the server itself be cleaning up
the environment it is passing to even non-suexec CGI? Perhaps it is...







Mime
View raw message