Friday, May 4. 2012
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.
So, right now you will probably want to use the following RewriteRule:
This is the easiest way to hot-fix the issue until a working PHP version is released.
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.
Read the original advisory here and my earlier article here.
Posted by Christopher Kunz
Comments (6) Trackbacks (7)
Defined tags for this entry: 5.2, 5.4, CGI, CVE-2012-1823, exploit, mitigation, mod_rewrite, PHP, remote code execution, vulnerability
Tracked: May 04, 19:55
Tracked: May 04, 22:51
Tracked: May 05, 11:01
Tracked: May 06, 18:15
Tracked: May 07, 05:19
Tracked: May 07, 07:58
Neue PHP-Lücke bedroht CGI-Installationen
Eine neue Lücke, die letzte Woche zufällig (lies: unabsichtlich) veröffentlicht wurde, hält derzeit die PHP-Entwickler in Atem. Der Fehler, der seit mindestens 2004 existiert, ist auf eine fehlerhafte Implementierung der CGI-Spezifikation zurückzuführen.
Tracked: May 08, 10:10
Display comments as (Linear | Threaded)
I think this problem is in Apache CGI implementation. Query string is supposed to be given to CGI program in environment variable QUERY_STRING not in command line arguments.
The problem is not Apache but RFC 3875 which says:
You are right, of course. The inverse of “SHOULD NOT” is “MAY”. However, I have no idea when the “MAY” would make any sense instead of “SHOULD”.
Generally, I don’t see why user-supplied input should be passed to the command line of a CGI binary in any case.