> -----Original Message----- > From: replies-lists-php@xxxxxxxxxxxxxxxxxxxxx [mailto:replies-lists- > php@xxxxxxxxxxxxxxxxxxxxx] > Sent: Monday, August 08, 2005 11:49 AM > To: Marc Powell > Subject: Re: Environment Variable contamination between vhosts - > 1.3.33 > > > > > > Date: Monday, August 08, 2005 09:34:50 AM -0700 > > From: Rasmus Lerdorf <rasmus@xxxxxxxxxxx> > > > > Marc Powell wrote: > >> Hi all, > >> > >> First time poster here so I apologize in advance for any gaffs. I've > >> Googled, searched the archives and the FAQ but can't find anything > >> close to what I'm experiencing. > >> > >> I have apache-1.3.33, mod_ssl-2.8.22 (with patches), php-4.3.2 (with > >> patches, 4.4.0 tested as well), mod_perl-1.29-5 (with patches) running > >> with the following additional modules -- > >> > >> mod_jk.c, mod_ssl.c, mod_php4.c, mod_perl.c, mod_setenvif.c, mod_so.c, > >> mod_unique_id.c, mod_headers.c, mod_expires.c, mod_auth_db.c, > >> mod_auth_anon.c, mod_auth.c, mod_access.c, mod_rewrite.c, mod_alias.c, > >> mod_userdir.c, mod_actions.c, mod_imap.c, mod_asis.c, mod_cgi.c, > >> mod_dir.c, mod_autoindex.c, mod_include.c, mod_info.c, mod_status.c, > >> mod_negotiation.c, mod_mime.c, mod_log_referer.c, mod_log_agent.c, > >> mod_log_config.c, mod_env.c, mod_vhost_alias.c, http_core.c > >> > >> all on RHEL 3.5. This server is handling a half dozen HTTP/HTTPS vhost > >> pairs. Each vhost is running on a separate IP ala -- > >> > >> Listen 1.1.1.1:80 > >> Listen 1.1.1.1:443 > >> <VirtualHost 1.1.1.1:80> > >> ... > >> </VirtualHost> > >> <VirtualHost 1.1.1.1:443> > >> ... > >> </VirtualHost> > >> > >> Listen 1.1.1.2:80 > >> Listen 1.1.1.2:443 > >> <VirtualHost 1.1.1.2:80> > >> ... > >> </VirtualHost> > >> <VirtualHost 1.1.1.2:443> > >> ... > >> </VirtualHost> > >> > >> And so forth... We discovered a problem where the HTTPS environment > >> variable was incorrectly being set to ON for normal HTTP requests for > >> one of our vhosts running SquirrelMail. Further investigation revealed > >> that a number of environment variables were being cross-contaminated > >> between virtual hosts. For example, running phpinfo() under > >> VirtualHost 1.1.1.1 would yield the following on one request (with no > >> contamination) -- > >> > >> _SERVER["REMOTE_ADDR"] 172.27.a.a > >> _SERVER["REMOTE_PORT"] 3477 > >> _SERVER["SCRIPT_FILENAME"] /path/to/phpinfo.php > >> _SERVER["SERVER_ADDR"] 1.1.1.1 > >> _SERVER["SERVER_ADMIN"] noc@xxxxxxx > >> _SERVER["SERVER_NAME"] my.vhost1.foo > >> _SERVER["SERVER_PORT"] 80 > >> _SERVER["SERVER_SIGNATURE"] no value > >> _SERVER["SERVER_SOFTWARE"] Apache > >> _SERVER["UNIQUE_ID"] QvPfa38AAAEAAEgoDnc > >> _SERVER["GATEWAY_INTERFACE"] CGI/1.1 > >> _SERVER["SERVER_PROTOCOL"] HTTP/1.0 > >> _SERVER["REQUEST_METHOD"] GET > >> _SERVER["QUERY_STRING"] no value > >> _SERVER["REQUEST_URI"] /phpinfo.php > >> _SERVER["SCRIPT_NAME"] /phpinfo.php > >> _SERVER["PATH_TRANSLATED"] /path/to/phpinfo.php > >> _SERVER["PHP_SELF"] /phpinfo.php > >> > >> And a few _ENV[] variables set such as HOSTNAME, etc... A refresh > >> however might return the following additions -- > >> > >> _SERVER["REMOTE_ADDR"] 172.27.a.a > >> _SERVER["REMOTE_PORT"] 2901 > >> _SERVER["SCRIPT_FILENAME"] /path/to/phpinfo.php > >> _SERVER["SERVER_ADDR"] 1.1.1.1 > >> _SERVER["SERVER_ADMIN"] noc@xxxxxxx > >> _SERVER["SERVER_NAME"] my.vhost1.foo > >> _SERVER["SERVER_PORT"] 80 > >> _ENV["HTTPS"] on > >> _ENV["REMOTE_ADDR"] 66.5.b.b > >> _ENV["REMOTE_PORT"] 4947 > >> _ENV["SCRIPT_FILENAME"] /path/to/some/other/site/login > >> _ENV["SERVER_ADDR"] 1.1.1.2 > >> _ENV["SERVER_ADMIN"] noc@xxxxxxx > >> _ENV["SERVER_NAME"] my.vhost2.foo > >> _ENV["SERVER_PORT"] 443 > >> _ENV["SERVER_SIGNATURE"] no value > >> _ENV["SERVER_SOFTWARE"] Apache > >> _ENV["ssl-unclean-shutdown"] 1 > >> _ENV["UNIQUE_ID"] QvPfr38AAAEAAEgqEyQ > >> _ENV["GATEWAY_INTERFACE"] CGI-Perl/1.1 > >> _ENV["SERVER_PROTOCOL"] HTTP/1.1 > >> _ENV["REQUEST_METHOD"] POST > >> _ENV["QUERY_STRING"] no value > >> _ENV["REQUEST_URI"] /login > >> _ENV["SCRIPT_NAME"] /login > >> > >> Essentially, I am seeing the environment variables (at the least) for > >> someone else's request to a completely different vhost on a completely > >> different Listen IP. Has anyone seen this before? Any direction where > >> to look? I've tried disabling mod_env just to see if that was it but > >> it had no effect. I can't easily disable mod_perl or mod_php for > >> testing purposes as this is a production machine. I actually have two > >> machines that are experiencing this. Both are identical. I've been > >> searching for a about a week now but I apparently can't hit on the > >> right combination of terms ;) This is the first time I've ever seen > >> this in many years of using Apache and php and I'm concerned about > >> the security implications of this beyond as well as fixing > >> SquirrelMail ;) I've bounced this off the apache-users list and they > >> say that since their included printenv script only shows the > >> appropriate environment information that it's a php problem. I have a > >> general lack of understanding of the interaction between Apache and > >> PHP when it comes to the environment variables but it seems to me > >> that php has to be getting those from Apache. *shrug* > >> > >> Any hints or guidance would really be appreciated. > > > > These variables are set by Apache and PHP repopulates them on each > > request, so I don't really see how PHP could be causing this. > > > > -Rasmus > > > > since these variables come from apache you might want to write a quick > perl cgi script and see if you can replicate this issue. Using -- #!/usr/bin/perl ## ## printenv -- demo CGI program which just prints its environment ## print "Content-type: text/plain\n\n"; foreach $var (sort(keys(%ENV))) { $val = $ENV{$var}; $val =~ s|\n|\\n|g; $val =~ s|"|\\"|g; print "${var}=\"${val}\"\n"; } I do not see the issue. This is why the apache guys thought it was a php issue. -- Marc p.s. I changed the reply-to to keep it on-list. I don't know where 'replies-lists-php@xxxxxxxxxxxxxxxxxxxxx' goes. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
