Hello!

> Thank you for your contribution, but IMHO this patch is not necessary 
> because the problem comes from Apache not allowing the Authorization 
> header to be added as an environment variable (Header => HTTP_HEADER 
> transformation).  See the httpd-2.2.4 source,server/util_script.c:173.

Ok, sure, that's true (but see below). But Apache has a VERY GOOD reason
to do so for normal CGIs!

Problem is that if you're using normal CGIs, Apache does the following:
It fork()s into a new process and then calls (after some cleanup)
execve() (or another exec* syscall). The environment of the newly
executed process is set accordingly to the CGI spec, i.e. all Header: is
passed as HTTP_HEADER. This is done for all headers except Authorization.

So why isn't it done for authorization? If the header were part of the
initial (!) environment, it could be accessed by ANY process with the
same user id. So if ANY process running under the Apache user id called
'ps e' or read the corresponding /proc files manually, it could
determine the contents of the Authorization header and sniff passwords.

Suexec makes this attack much more difficult because of two reasons:
First of all, the time during which the environment of the process may
be read is VERY short and second of all, the CGI scripts of other users
on the same server are normally not executed with the same user id as
the Apache user (if suexec is used at all, it is probably used for
everything). Still, it would be possible to trick Apache into accessing
the /proc files itself using FollowSymLinks etc.

That's why Apache only supports this via the compile-time flag
SECURITY_HOLE_PASS_AUTHORIZATION.

Because it CAN be used safely with normal CGI (use suexec for EVERYTHING
without exception, NEVER allow FollowSymLinks but only
SymLinksIfOwnerMatch, look out for similar Problems with e.g. SSI etc.)
but it would be VERY difficult for the normal sysadmin to do so. That's
why the Apache people chose to do as they did.

With FastCGI this is NOT a problem anymore. Because FastCGI does not
pass HTTP header variables as the INITIAL environment to the process but
rather uses sockets for passing the simulated environment variables,
this security hole simply does not exist anymore with FastCGI. But this
does not change the CGI problem.

> OTOH, PHP as a CGI or FastCGI executable does exactly what it is 
> supposed to do: reading environment variables, not headers (e.g. PHP 
> parses the HTTP_ACCEPT_LANGUAGE env variable, not the "Accept-Language" 
> header.).

Yes, PHP behaves correctly in this way, that's kind of my point. ;-)

> The PassHeader directive doesn't have to exist because translating _all_ 
> headers to HTTP_ vars belongs to web server, not the cgi or fastcgi module.

Well, my patch didn't invent the PassHeader directive. ;-)

The point of my patch simply is: IF you provide a directive called
PassHeader (which you currently do!), then it should behave correctly.
Currently, you provide that directive but it sets the name of the
environment variable to the literal name of the header - it doesn't
uppercase it and it doesn't add the HTTP_ prefix.

You have three options in my eyes - but neither of them is the current
behaviour of mod_fcgid:

1. Don't provide the PassHeader configuration option at all and state
that if anybody wants to use the Authorization header they should
recompile Apache with the -D.... flag. Personally, I find that to be a
very bad idea because that will open a security hole regarding normal
CGI (which may be necessary to coexist with FastCGI).

2. Don't provide the PassHeader configuration option but ALWAYS add the
Authorization header as HTTP_AUTHORIZATION manually in mod_fcgid.

3. Provider the PassHeader configuration option but make it work
correctly (see my patch).

>> Oh, and just a general question: Why aren't all mod_fcgid configuration
>> directives prefixed with e.g. Fcgid? If I see configuration directives
>> like 'MaxProccessCount' or 'SocketPath' I don't automatically associate
>> them with mod_fcgid - if they were named 'FcgidMaxProcessCount',
>> 'FcgidSocketPath' or something similar, it would be clear from the start
>> to which module they belong.
> 
> This is a very good suggestion (and already mentioned), but nobody has 
> done a patch yet. Maybe for the next version ?

If you're interested, I could write it? Shouldn't be too much work and I
could keep the old names as deprecated aliases that only throw warnings
in the error log in order to maintain configuration compatibility.

Regards,
Christian

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Mod-fcgid-users mailing list
Mod-fcgid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users

Reply via email to