httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: suexec concerns
Date Sat, 04 Jan 1997 00:08:46 GMT
On Fri, 3 Jan 1997, Randy Terbush wrote:

> > On Fri, 3 Jan 1997, Randy Terbush wrote:

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

Sorry, you're right.  I was thinking of something else.  There is some
nagging thought at the back of my mind that I can't think of right now. 
There is a race condition between when it checks the file and when it
executes the file, but that would only be a problem if the attacker had
write permission to a directory higher in the docroot tree above the cgi; 
then they could substitute their own program between when the check is
done and when the program is executed by suexec.  However, I don't _think_
that is much to worry about but there could be some other gotcha in there. 

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

Quite.  Or you can have the webserver write out the PassEnv and SetEnv
commands to a seperate file so that suexec can quickly read it at start
up.  I agree that the overhead would be a bit much for most people to try
to track down all the mod_env directives each time it is run, especially
since I don't think most people use mod_env. 

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

Sounds like a good start.  

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

Yes.  Unless I have missed any, the above list is all that the server will
pass to things like CGIs, so it is safe to limit what suexec accepts to
that without losing anything.  The server doesn't pass anything of the
original environment on to CGIs (well, unless you use mod_env) but creates
an entirely new one.  Remember, the name of the game is to stop the bad
guys; they wear black hats and run suexec from the command line after
compromising HTTPD_USER. 



Mime
View raw message