Date: Wed, 5 Sep 2012 13:05:43 -0400 (EDT) From: cve-assign@...re.org To: oss-security@...ts.openwall.com Cc: cve-assign@...re.org Subject: Re: php header() header injection detection bypass -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >To me, this is what each of the ids represent: >CVE-2011-1398: describes the protection bypass >CVE-2012-4388: describes the failure to fully fix the protection bypass >(hence the "incomplete fix for CVE-2011-1398") OK, what seems best at this point is the following: [revised CVE-2011-1398 description] The sapi_header_op function in main/SAPI.c in PHP before 5.3.11 and 5.4.x before 5.4.0RC2 does not check for %0D sequences (aka carriage return characters), which allows remote attackers to bypass an HTTP response-splitting protection mechanism via a crafted URL, related to improper interaction between the PHP header function and certain browsers, as demonstrated by Internet Explorer and Google Chrome. [new CVE-2012-4388 description] The sapi_header_op function in main/SAPI.c in PHP 5.4.0RC2 through 5.4.0 does not properly determine a pointer during checks for %0D sequences (aka carriage return characters), which allows remote attackers to bypass an HTTP response-splitting protection mechanism via a crafted URL, related to improper interaction between the PHP header function and certain browsers, as demonstrated by Internet Explorer and Google Chrome. NOTE: this vulnerability exists because of an incorrect fix for CVE-2011-1398. Note 1: We originally thought that there was interest in separate CVE IDs for "the header function is unsafe when a URL contains any recognized end-of-line character" and "the header function is unsafe when a URL contains a %0D sequence." If this were the case, the second CVE description would mention an "incomplete fix" for the first CVE. But, we now understand that the first CVE is not wanted at all, which seems reasonable. In the actual situation, the https://bugs.php.net/patch-display.php?bug_id=60227&patch=SAPI.diff&revision=1320563128 patch had a logic flaw related to the "((p = memchr(s, '\n', (e - s))) || (p = memchr(s, '\r', (e - s))))" expression. MITRE prefers to categorize this type of situation as an "incorrect fix" not an "incomplete fix." Admittedly, for many CVE users it doesn't matter. The mapping of the two CVEs to a vendor changelog is currently problematic because http://www.php.net/ChangeLog-5.php has two very similar references to "Fixed bug #60227" but one of the listed versions (5.4.0) has the code change with the above-mentioned logic flaw, whereas the other (5.3.11) has a different code change without this logic flaw. Note 2: We probably haven't found the exact affected 5.4.0RC versions, but this doesn't matter much because those versions aren't widely used. Specifically, we don't know whether there's a supported download location for every pre-release version that ever existed, but we happened to find the http://php.marvel.strk.jp/archive/ directory. Here, 5.4.0alpha3 (August 2011) does not check for '\r' at all, whereas 5.4.0RC2 (December 2011) can check for '\r' but has the above-mentioned logic flaw. This is consistent with the 2011-11-06 SVN date listed in bug 60227. - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (SunOS) iQEcBAEBAgAGBQJQR4VAAAoJEGvefgSNfHMdT2cIAKLrbO/VRVzYstBpTXdDWe/i n7h1ihiDHjClMClApGx6EfzGgZ5sueAtFUkDvbxjp1yvCBYTmioOpAuaXZKEFXk2 EgTYrNrPIRMpss0FnM+6ORVnnfZh7TlfipHnkICYLjbf901R02ijxVseeK4IkIlJ CN65rm65hu2qb/rdCeei/buTv+cp77xdZCkO+NeAj4VmC14/eVtTbXP5pkG73kxG OLkL9oQY/Inbdi2jR5oIHBKSW6EG2Nu9kXO6uX1L6FPcxTGN1TiRhKZo6pLicYg6 CCiiCAR8hIB1+v1gLi8R0JfBBxF9q1LbyjnrowGNitiq305QSptBA1zLe2977O8= =cX+c -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ