Place a "php.bat" in the Apache cgi-bin directory containing commands:
This prevents PHP from receiving command line parameters, and thus
defeats the exploit.
The changes to PHP are very simple. Update the documentation to for
Apache on Windows to use the above setup. Remove the test that tries
(poorly) to detect if PHP were called safely.
It detects and works just fine, and removing it would open more systems to the exploit because noone is going to read the docs.
Apache sets an environment variable when it does a redirect to a script interpreter. If php is compiled to check the redirect, then it will not operate if it has a CGI environment, the redirect environment variable does not exist. This removes the necessity, on both windows and linux, of the workarounds you mention.
The problem was that the windows version of PHP was never compiled WITH the redirect check. Therefore, following normal Apache configuration instructions, windows/apache/php was open to exploit. The solution was to compile php on windows with the redirect check.
IIS does not need this check, and in fact will not work with the check enabled. So, you set cgi.force_redirect=0 in php.ini, and the check is ignored.
The problem is documentation and installation. The php windows installer should set the php.ini entry apropriately for what web server it is installing onto. For upgrades, users should read the change notes and documentation to see how the upgrade will effect them.
Since users DONT read that information before upgrading, the desire was/is to make the check more transparent so it would not immediately break under IIS. I'm not certain if that is possible.
Shane