httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <ra...@zyzzyva.com>
Subject Re: SUID layer for Apache CGI implementation...
Date Mon, 03 Jun 1996 18:22:13 GMT

> My design philosophy for suCGI was this:
> 	1.  Only call wrapper when absolutely necessary (i.e. userdirs).
> 	    This was implemented in the Beta-Carotene version.

Current state of call_exec only calls the wrapper for VHosts that
have a different Group or User set in their configuration.
This is stored in r->server->server_uid and r->server->server_gid.

Adding the ability to set the behaviour for user dirs would be nice.
Basing it on whether the URL contains '~' is not dependable since
that convention is not used on any of the servers I am running.

> 	2.  Make a messload of paranoia checks *before* calling the
> 	    wrapper.  This was not implemented in Beta-Carotene.

This is currently done in the can_exec() function in http_exec.c
I have included the same checks in my latest incantation of sucgi.c
which I will begin calling uscgi.c until a time when we can comfortably
call it scgi.c perhaps. :-)

> 	3.  Call suid layer.

I assume that by "suid layer" you are refering to the wrapper?

> 	4.  Suid layer would allow only a predefined user (i.e. the
> 	    server user) execute the code.
> 	5.  Suid layer would watch for OS-level weirdness only.
> 	6.  Suid layer would *build the path* to the executable.
> 	    Four, five, and six were all implemented in B-C.

I think that it is still possible to build the path without forcing
the CGI to reside in a specific directory. By forcing the CWD to
match a compiled in path to DocumentRoot would be a big step toward
security.


> To keep with this design philosophy of efficiency, any implementation
> should keep with the "stay internal until absolutely necessary" concept.
> For this to happen -- especially with allowing use of suCGI by virtual
> host or location -- some strong authenticity needs to be implemented so
> that only Apache server process can execute the code.  This -- to me --
> would assuage my fears of suCGI being exploited.
> 
> * Walk the process tree.  When executed, the wrapper would walk up its
> genealogical process tree to verify the parent is actually the allowed
> user and is the proper httpd executable image.  To me, this would be
> authentic enough (although I'm sure one of you wizards could prove me
> wrong).  I like this one best.  My question on this one would be
> efficiency.  Am I wrong?

I guess this would require us to search until the parentuid changed, and if
it changed to anything but root, die?

> * Pass a simple variable-target authentication pass-phrase.  This could be
> something like GMT seconds in a mirrored string.  Or it could be some
> other repeatable algorithm.  This is not preferable to the above, however,
> because this is another security-by-obscurity technique.

Since the source for this wrapper would be publicly available, I
think these sorts of authentication methods could be circumvented
by the hacker.

> * Verify Apache authenticity by reading some of the server pool for an
> authentication key of some sort...  Would preclude suid's access to memory
> pools.

Hmmm. Seems again that if the hacker has become 'www' then it would
be possible to fake up something here to convince the wrapper.
RST's paranoia having it's way with me... :-)






Mime
View raw message