I'm having some trouble tracking this down and since it directly affects the operation of SM I thought I'd send here as well. My problem in a nutshell is that the HTTPS environment variable is being incorrectly set to ON for non-https requests. This is because php's environment variables are being polluted by requests to completely independent vhosts on the same server. As a result functions/strings.php/get_location() is incorrectly building a link that looks like https://my.web.site:80/blah for non-https users intermittently. This is a vanilla install of apache and php so I'm a bit concerned from a security perspective as well. In any event, has anyone seen anything like this before? Essentially the symptoms are the same as the Mac issue where sending or deleting a message results in blank page, no page change or an error indicating that the connection was dropped, some data may have been transferred. I'm running SM-1.4.3a with some back-ported security patches. I've looked at strings.php in CVS and see that this function is identical.
TIA, -- Marc ---- 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"] [EMAIL PROTECTED] _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"] [EMAIL PROTECTED] _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"] [EMAIL PROTECTED] _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. Thanks. -- Marc Powell Senior Systems Engineer ENA/ConnecTEN [EMAIL PROTECTED] ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- squirrelmail-users mailing list Posting Guidelines: http://squirrelmail.org/wiki/wiki.php?MailingListPostingGuidelines List Address: [email protected] List Archives: http://news.gmane.org/thread.php?group=gmane.mail.squirrelmail.user List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id)95 List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
