Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 18 May 2015 23:15:54 -0400 (EDT)
From: cve-assign@...re.org
To: remi@...oraproject.org
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: About PHP and CVE-2015-1353

-----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-----

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ