Re: PHP-CGI query string parameter vulnerability (CVE-2012-1823 / CVE-2012-2311, CERT VU#520827)

[Kurt Seifried <kseifried () redhat com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/09/2012 12:59 PM, cve-assign () mitre org wrote:
> > The incomplete fix part seems to have got bit messy, at least
> > with respect to CVE assignment.
>
> The total number of CVE IDs should be 4. Comments below:
>
> > 1) Incorrect detection of = in query string, that made it
> > possible to bypass the fix using %3D.  This was addressed by:
>
> > -       if(*decoded_query_string == '-' &&
> > strchr(decoded_query_string, '=') == NULL) { +
> > if(*decoded_query_string == '-' && strchr(query_string, '=') ==
> > NULL) {
>
> > which is noted as Mitigation option 3 in De Eindbazen's blog. 
> > Following the timeline / updates there, this should be what
> > triggered CVE-2012-2311 assignment.
>
> CVE-2012-2311 is for only this specific %3D fix listed as "1)"
> above.
>
>
> > 2) The fix from 1) did not address the problem for use cases
> > where "unsafe" wrapper script, similar to the one pointed out in
> > De Eindbazen's blog, is used.  It seems that was first mentioned
> > in Christopher Kunz's (php-security.net) blog mentioning that the
> > PHP re-fix is still incomplete, though it's questionable if this
> > is to be considered a PHP flaw.  Upstream warned about this
> > insecure wrapper script problem:
>
> > http://www.php.net/archive/2012.php#id2012-05-06-1
>
> > and even added a fix / work around for it to PHP:
>
> > http://git.php.net/?p=php-src.git;a=blob;f=sapi/cgi/cgi_main.c;h=a7ac26f0#l1569
>
> >
> This needs a separate CVE ID (different from both CVE-2012-1823
> and CVE-2012-2311). MITRE is considering the "insecure wrapper
> script" to be a distributable product because the code has been
> available for some time on a public web site, and the (admittedly
> tiny) script codebase has apparently sometimes been copied and
> adapted for use at multiple web-hosting providers.
>
> The script codebase is, of course, open source.
>
> In many cases, MITRE would not bother to assign a CVE ID for a 
> vulnerability in a "product" of this type (i.e., a product that is 
> arguably not even packaged for distribution and does not even have
> a product name). However, in this case, the product and its 
> vulnerability have become commonly recognized and discussed because
> of the connection to the other PHP-CGI issues. Therefore, a CVE
> name is useful.
>
> This can be temporarily called CVE-2012-NEW-1.

Please use CVE-2012-2335 for these wrapper script issues


> > 3) The fix from 1) only made PHP skip one php_getopt() call out
> > of two that are reachable in the CGI mode (the third php_getopt()
> > call is in the if (!cgi && !fastcgi) block).  As the consequence,
> > PHP was still parsing following arguments:
>
> > - -h / -? - this seems harmless, as makes PHP output usage info,
> > which triggers Internal Server Error in httpd - -T - this was
> > mentioned as DoS vector:
>
> > https://bugs.php.net/bug.php?id=61910#1336220802 
> > http://www.php-security.net/archives/9-New-PHP-CGI-exploit-CVE-2012-1823.html
>
> >  The impact of this is rather limited as clients needs to consume
> > all generated output too keep this running.  May offer some
> > advantage of simple many requests DoS e.g. Keep-Alive is disabled
> > and there's per-IP connection limit.
>
>
> > This is upstream commit that was used in 5.4.2 / 5.3.12:
>
> > http://git.php.net/?p=php-src.git;a=commitdiff;h=168e8920be77f3b55a3ae688270b752579681f6e
>
> >  and this is correction from 5.4.3 / 5.3.13:
>
> > http://git.php.net/?p=php-src.git;a=commitdiff;h=000e84aa88ce16deabbf61e7086fc8db63ca88aa
>
> >  (both links are for PHP-5.3 branch commits).
>
> This one also needs a separate CVE ID (different from both 
> CVE-2012-1823 and CVE-2012-2311). Compared to CVE-2012-2311, it 
> apparently has the same "affected versions" relative to official 
> upstream release numbers. However, the affected versions are
> different in PHP packages from multiple Linux distributions. In
> this situation, it seems best to have two separate CVE names
> (CVE-2012-2311 and a new one) for the two different issues with
> php_getopt - in other words:
>
> CVE-2012-2311:   the vulnerability that exists when the php_getopt 
> for cases 'c' 'n' 'd' 'b' and 's' is not skipped
>
> CVE-2012-NEW-2:  the vulnerability that exists when the php_getopt 
> for cases 'T' and 'h' is not skipped

Please use CVE-2012-2336 for the cases 'T' and 'h'

> If this is agreeable, we would like Red Hat to make the specific
> CVE assignments for the "CVE-2012-NEW-1" and "CVE-2012-NEW-2"
> labels referenced above. If, for any reason, Red Hat doesn't want
> to make these two CVE assignments, please let us know.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPqtHOAAoJEBYNRVNeJnmTN/oP/j6s/0YrCOnDiQSx5S1rT+SI
0PO6ELz0mAw5Suy5AIvj4OypjhqZcIg18DP4b14OvsM4bHC+Ue7mf4mgMzTexl7s
94osRLQ5uwnhRTVHTmt/Iil9No2vWhz6rRQJnCz93OYABZUluQYEpo6zkzKNGlui
adIhYIrdt49Cp2P8V2VuaJ5XNA3d+h0w4NF/weT8q8R03lptmOKKyV0RziNEgXri
CybiFeJW8wpI6BdizVa/SJV90fQi+E88HOR/5VxeMVAYW7aCwZZEaquOKlcS0hgu
XP/do2Xl3MS693G+vpyFIxzdrIEuGJEujYUxO1gd+FO7FCRnAuHQBKBhaQ1+vUr2
ILWWSsMsIE+Go9KHmLRghrCZaPZZ2wu45edVLoVIKzLNCsXOH017RRGlPovnEKs6
afZPgKrfDthsV06i4MLxaGpgkFEXrN+P3Xmx5W8vKmClNWibbjvlnsbEHhgaeYpI
3YwVKapKHEnNAvkz2HKlu1JwmnWw4t66cCz09ipHX++JMWXajyhDqkGihtTmOkaY
re/K0XwqOFj49sADf3B0rm8RBMLAiRAvB5n/6FoQbxDGRf8aqehyd0jv5Ce4JOb+
pgB+NrA+uQ3Ywlms6JV7GOmQqcE58+X66kKjDW5dm7ohaezLTDVxzdNvS9QrG9lg
XZQV6nn7rDjmtCxySaiy
=GhGj
-----END PGP SIGNATURE-----