Re: SUID layer for Apache CGI implementation...

[Randy Terbush <ra...@zyzzyva.com>]

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

Re: SUID layer for Apache CGI implementation...

["Jason A. Dour" <ja...@bcc.louisville.edu>]

-----BEGIN PGP SIGNED MESSAGE-----

On Mon, 3 Jun 1996, Randy Terbush wrote:
> 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.

	Good.

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

	Oh.  I forgot...not everybody does the tilde thing.  8)  IMHO, if
it doesn't have a tilde, then it isn't a userdir.  But I guess we could
have a UserDirPrefix option that allows you to specify '/users/' if your
URLs are /user/someuser/index.html and /user/otheruser/index.html.  What
about that?  Could this be made into a more general patch for
Apache...allowing people to specify their userdir prefixes?  I'd rather
see something more generic than a suCGIUserDirPrefix directive.  8)

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

	HAHA.  OK.  I'm still not certain that we need to duplicate the
effort.  If the authentication is tight enough, then I would rather see
the checks in one place or another.  Preferably internal...it would be
more efficient. 

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

	Yup.  Sorry.

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

	Agreed.

> > * 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?

	I was thinking steps more along the lines of (switch into program
emulation here): 

	OK.  I'm born.  Great.
	Is my *effective UID and actual UID* name the same as <VALID_USERID>?
	Is my mommy's *E* and *A* name NOT root?
	Is my mommy's *E* and *A* name <VALID_USERID>?
	Is my mommy an instance of <PATH TO HTTPD IMAGE>?
        Does my mommy have a mommy?
          If so, is my mommy's mommy's *E* and *A* name <VALID_USERID>?
          Is my mommy's mommy an instance of <PATH TO HTTPD IMAGE>?

Something along those lines.  But the idea of stepping up until the euid
is root isn't bad either...providing the server isn't started as some
other user.  Granted, the daemon user then becomes a higher risk...but
some sites need to weigh customer demand and risk.  Some will choose risk.
(Before someone vents...I'm all for a secure piece of code...but people
opting for risk is a reality.)

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

	Agreed.

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

	Again...risk versus demand.  I'm not saying it's right...but a
reality.  The comment made about being careful what goes into a product is
also quite accurate...  However, there are other pieces of software that
bank functionality on daemon user priveledge.  I don't see why Apache
can't be similar.  Not by default, certainly.  I think it should be an
*option* that is heavily documented with BIG caveats. 

Jason
+ Jason A. Dour                       jad@bcc.louisville.edu               +
| Programmer Analyst II               http://www.louisville.edu/~jadour01/ |
| Dept. of Radiation Oncology         Finger for Geek Code, PGP Public Key,|
+ University of Louisville            PJ Harvey info, and other stuff...   +

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMbMzXJo1JaC71RLxAQEY1QQAlLpR/D0H95vJmSLCco9AweRQn1oDRaaM
rntOqprYgEdaWisqXdSCFW6eptthPPG6eVdJIHS1SDvqRCRjwCiX34s/gkU9kU56
FeREk2Kf9w0+fNrSzcoiMkD7gxlX9aSoo+OsNZmU7T6/d87XBSbG9obGA/NMlFft
jhKxbqtedtI=
=FZob
-----END PGP SIGNATURE-----