[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120509203740.GO1992@redhat.com>
Date: Wed, 9 May 2012 14:37:40 -0600
From: Vincent Danen <vdanen@...hat.com>
To: oss-security@...ts.openwall.com
Cc: cve-assign@...re.org, thoger@...hat.com, security@....net
Subject: Re: PHP-CGI query string parameter vulnerability
(CVE-2012-1823 / CVE-2012-2311, CERT VU#520827)
Would probably be useful to have cc'd s@....net so they're aware of the
CVE assignments and the rationale behind them.
* [2012-05-09 14:21:34 -0600] Kurt Seifried wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 05/09/2012 12:59 PM, cve-assign@...re.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-----
--
Vincent Danen / Red Hat Security Response Team
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
