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