Mitigation for CVE-2012-1823 / CVE-2012-2311?

So PHP 5.4.2 and 5.3.12 do not fix the security issue reported in CVE-2012-1823 and discussed here earlier. The original advisory has a number of mitigation opportunities and an additional patch, and PHP.net has a RewriteRule online as a hotfix.

Update As mentioned on Eindbazen: The current fixes have a problem with whitespace BEFORE the actual Query String, i.e. “/?+-s”. This only applies in the wrapper environment outlined by eindbazen.net where command-line arguments are passed without double quotes to PHP, as in /usr/bin/php5 $@.

I want to discuss now shortly if any of these properly mitigate the issue.

1. PHP 5.4.2 does not mitigate the issue.
   
2. RewriteRule on php.net: The RewriteRule posted on PHP.net is useless. I can’t go into much detail here but it does not mitigate the issue properly.
   
3. RewriteRule on bugs.php.net: The comments in the original advisory show a RewriteRule that was posted on bugs.php.net originally. I tried this against an unpatched PHP 5.3.3-7+Squeeze8 and it seems to correctly filter all malicious query strings, including my variations. It has a tiny bit of overshoot though (for example, passing negative integers to the query string will trigger a 403), but it’s not practically relevant, I think.
   
4. Binary Wrapper and Option-stripping patch on eindbazen.net: The guys who wrote the original advisory wrote a patch and a php-cgi wrapper that strips all “-xyz” options respectively skips option processing when in CGI mode. This works well, too.
   
5. Patch “third option” on eindbazen.net: This patch does not properly mitigate the issue.
   

So, right now you will probably want to use the following RewriteRule:

RewriteEngine on

RewriteCond %{QUERY_STRING} ^[^=]*$

RewriteCond %{QUERY_STRING} %2d|\- [NC]

RewriteRule .? - [F,L]

In the meantime, CVE-2012-2311 has been issued to address the fact that PHP 5.4.2 and 5.3.12 (which I never tested, btw, but the patch is identical) do not properly fix the problem.