oss-sec mailing list archives
Re: About PHP and CVE-2015-1353
From: cve-assign () mitre org
Date: Mon, 18 May 2015 23:15:54 -0400 (EDT)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On bad input, the call will produce a bad output. I don't see any way to exploit this for any bad thing. I really think we should reject this CVE. Upstream doesn't even consider this as a bug.
Multiple integer overflows in the calendar extension in PHP through 5.6.7 allow remote attackers to cause a denial of service or possibly have unspecified other impact via a crafted year value to (1) the GregorianToSdn function in gregor.c or (2) the JulianToSdn function in julian.c, as demonstrated by a crafted third argument to the gregoriantojd or juliantojd function.
We are rejecting this CVE because there is, in effect, a specification indicating that PHP would not be the responsible product for any security issue related to a large number in the third argument to the gregoriantojd or juliantojd function. The http://php.net/manual/en/function.gregoriantojd.php and http://php.net/manual/en/function.juliantojd.php pages state: year The year as a number between -4714 and 9999 year The year as a number between -4713 and 9999 (Similar documentation has existed for several years, probably going back to when gregoriantojd and juliantojd were first implemented.) The integer overflow occurs for a year much larger than 9999 (approximately 1.47 million). This violates the specification, and it is reasonable for PHP's behavior to be undefined. It's conceivable that an open-source application exists with a security impact for untrusted input of a year such as 1.47 million: in that case, a CVE ID could be assigned to that application. (In other words, a CVE can exist for an integer overflow that is relevant only because of business logic. A CVE for an integer overflow does not require the overflow to have any effect on memory safety.) - -- 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.14 (SunOS) iQEcBAEBAgAGBQJVWqpkAAoJEKllVAevmvmsAxsIALNWNhkrF21EIeVWqvDTkrwz 99ldxVEIVbtDR8o2ouzKQrBVMZNI0lmDQ2qzVBtdKwf9oWIjTOYvsgQtuqDDRFOU Ab0RJl+6CnY8tvFVCZh7Y2IoYz3GM3BnAVF0fyXygnI2cPcfq6jWAOHNw1iikWOp 9PfqGEkq1kJpNzD+qGG30Get9UfzPwi5IyXfMDhUWB9in7bgYPfkn2IOiTlgRXA6 wTxhdM+oV6QfrDQBe8NDscMl89Fhu7qotiRexQiPLifEs0O+LfptxckcSyPW+dkT RmeIwq2HOsBeGCcDcSWKXLHCCqqFilso99E8IjJ1jgf00+gDmV5j+nFA2KIilSc= =AJ8l -----END PGP SIGNATURE-----
Current thread:
- About PHP and CVE-2015-1353 Remi Collet (May 05)
- Re: About PHP and CVE-2015-1353 - please REJECT Remi Collet (May 11)
- Re: About PHP and CVE-2015-1353 cve-assign (May 18)