httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <ra...@zyzzyva.com>
Subject Re: setuid() again
Date Mon, 01 Jan 1996 19:44:17 GMT

> > > > * cgiwrapper
> > > > 
> > > >    Disables the ability to have index.cgi
> > > 
> > > So fix it.
> > 
> > 'cgiwrapper' is not really designed with this in mind. My 'fix'
> > is what I propose.
> 
> OK, lets go over the problem a step at a time. Why/how does it disable this
> ability?


> > > >    Some support issues with explaining it's use.
> > > 
> > > And integrate its use tightly into Apache.
> > 
> > Which is what the seteuid() stuff does.
> 
> At considerable extra danger.

What extra danger?

There are an endless amout of unknowns. There are tangible benefits
to security by forcing CGI execution to unique users.


> > > > Most changes can be restricted to can_exec().
> > > > 
> > > > We can:
> > > > 	disallow execution of any CGI by uid 0.
> > > 
> > > You should disallow all serving of anything by uid 0.
> > 
> > Which is done.
> 
> It is? How?

can_exec() (as I have it running):

* will not exec/include anything that is *not* a regular file.
* will not exec/include anything that is uid 0.
* will not exec/include anthing that is group/world writable.

only after can_exec() has checked the safety of the file, will
it be passed on for execution. seteuid() (now setuid())is called
the line before the exec.

The changes to can_exec() are probably a good idea even if we did
not allow the seteuid().


> > The solution would probably be to run in a chroot()ed environment.
> 
> Hmmm - then you have to copy all the utilities they might use into local
> directories. As well as shared libraries, device files, etc.

I run a fairly standalone environment with exception of shared libs,
so I could fairly easily do this.


> > You are not processing the request as root. The server does a seteuid(0),
> > immediately followed by a seteuid("owner of script"), processes the request
> > as the owner of the script, and  then returns to being "nobody" or whomever
> > you have chosen to run as.
> 
> Hmmm - stricly Apache should run in a mode where seteuid(0) doesn't work.

I went to work to see the effects of this.... and found a Mac Truck size
hole in the way the seteuid() stuff was being done. (I told you so for
everyone!)  :-)

However, changing the seteuid(destid) to be a setuid(destid) fixes the
problem. I also verified that 1.0.0 is calling setuid() which closes
the door to seteuid later.

I realize that bugslike this are yet another argument for those
opposed to this change. I understand that I may have to resolve myself
to patching the stock distrib to get this functionality. The attractivness
for script developers to be able to turn off read access to the world
far outweighs the potential problems here.

The suggestion of creating a separate daemon to handle this has been
discussed before. I think that it potentially could bloat into an
equally dangerous piece of code when popularity grows for this feature.

I have removed the patch that was in for_Apache_1.1b0 to prevent
anyone else from running it. I highly recommend removing the changes
if anyone is running them. (made my heart stop...)

Can someone comment on what restrictions there are to dynamically loading
a module? This could be an even more dangerous hole if a user could
convince Apache to load their own module.






Mime
View raw message