It was discovered that the fix that was applied in PHP versions 5.3.12 and 5.4.2 to address CVE-2012-1823 (bug #818607) was incomplete and did not resolved the problem. A remote attacker could still use this flaw to remotely execute arbitrary code on the servers using affected PHP CGI configurations. The problem was noted in the blog post of the CVE-2012-1823 issue reporter: http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/ UPDATE3: The new PHP release is buggy. You can use their workaround, but the new releases and their patch do not fix the issue. Use our mitigations for now. [...] UPDATE5: We have received word that new PHP updates with the revised fix will be released soon. The issue that this problem was not properly fixed by the original security update is being tracked as CVE-2012-2311. [...] Additional references: http://www.php-security.net/archives/11-Mitigation-for-CVE-2012-1823-CVE-2012-2311.html https://lwn.net/Articles/495905/#CommAnchor495919
Since Red Hat did not release packages with an incomplete fix for CVE-2012-1823, this CVE does not affect any Red Hat products.
Well Mark's statement isn't accurate anymore: https://rhn.redhat.com/errata/RHSA-2012-0546.html https://rhn.redhat.com/errata/RHSA-2012-0547.html And looking at that patch: + if(*decoded_query_string == '-' && strchr(query_string, '=') == NULL) { Yes, how about decoded_query_string not starting with - but with a space? Request like: http://example.org/my.php?+-s On a sidenote, I think this is more Apache bug than PHP bug as if you run any other program similary configured in Apache you can give command line arguments to it with query string.
Jani - the fix shipped in RHSA-2012-0546 and RHSA-2012-0547 is sufficient to prevent the attack except in the case where an unsafe wrapper script is used with php-cgi. As described by De Eindbazen in the link above: php-wrapper.fcgi is a shell script that wraps php5-cgi, which has the aforementioned -s option. ... Edit: (Note that the shell-script is inherently insecure because it does shell expansion, the correct way to pass on arguments would be "$@") It is only in the case where a wrapper script is insecurely using $* to pass through the command-line arguments that the fix shipped is insufficient to prevent the attack. With respect to your note on Apache: the expected behaviour here is standardised by the CGI specification, and httpd does actually implement the spec.
(In reply to comment #3) > Jani - the fix shipped in RHSA-2012-0546 and RHSA-2012-0547 is sufficient to > prevent the attack except in the case where an unsafe wrapper script is used > with php-cgi. That is also noted in bug 818607, comment #31.
(In reply to comment #2) > Well Mark's statement isn't accurate anymore: Mark's statement is still correct with respect to the use of this CVE, but not correct if read as "there's not issue with the released CVE-2012-1823 fixes". This clarifies which CVEs were assigned for the problems that the original CVE-2012-1823 fix had: http://thread.gmane.org/gmane.comp.security.oss.general/7600/focus=7635 CVE-2012-2311 - This CVE is only to be used for the incorrect detection of '=', which allows bypassing the check introduced in PHP versions 5.3.12 and 5.4.2 by using %3D in the query string. Red Hat released updates correcting CVE-2012-1823 did not have this problem, hence this CVE is not applicable to Red Hat Enterprise Linux PHP packages. CVE-2012-2335 - This was assigned for an insecure wrapper script. This is not CVE for PHP itself. Upstream PHP versions 5.3.13 and 5.4.3 mitigated this problem by skipping leading spaces in the query string before doing other checks. As pointed out in comment #2, this mitigation is not included in the Red Hat PHP packages updates fixing CVE-2012-1823. This fix may be included in future updates, however fixing such scripts is recommended (see bug 818607, comment #31). CVE-2012-2336 - This CVE is for the problem that the second php_getopt() call was not skipped, and hence with the original fix applied, php-cgi would still handle injected -h/-? and -T options. That issue was not corrected in Red Hat PHP packages updates fixing CVE-2012-1823 and is tracked via separate bug #820708. Statement: Not vulnerable. Red Hat did not release PHP package updates addressing CVE-2012-1823 that introduce the CVE-2012-2311 issue. Therefore, this CVE does not affect any Red Hat products.