Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96635
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <573da963-6121-3231-b603-4c5d6b332c9d@fedoraproject.org>
References: <1ae4bea0-d62b-fd61-f6b6-55762e97df6e@gmail.com> <573da963-6121-3231-b603-4c5d6b332c9d@fedoraproject.org>
Date: Fri, 28 Oct 2016 17:33:23 +0200
Message-ID: <CAH-PCH7O2SoBcfzYdAupTYTWVpuiQWriSMaJi7nWMUbSDzU9oQ@mail.gmail.com>
To: Remi Collet <remi@fedoraproject.org>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e013d0f1a27a3a1053fee94f6
Subject: Re: [PHP-DEV] bug classification discussion
From: tyra3l@gmail.com (Ferenc Kovacs)

--089e013d0f1a27a3a1053fee94f6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 28, 2016 at 11:18 AM, Remi Collet <remi@fedoraproject.org>
wrote:

> Le 24/10/2016 =C3=A0 07:23, Stanislav Malyshev a =C3=A9crit :
> > Hi!
> >
> > We have had a bunch of bugs recently which are essentially one and the
> > same issue: PHP 5.6 allows only int-sized strings, but many functions
> > don't check the size of the string they produce. This can lead to int
> > overflows inside php and also can break other libraries that also assum=
e
> > string sizes are ints and this can cause all kinds of weirdness.
> > However, these bugs are very unlikely to manifest in production setting
> > for one simple reason - they require PHP to run with no memory limit,
> > and I haven't seen many setups that run with no memory limit. I'm not
> > going to go into specifics here, since some of the issues are still not
> > fixed, but you can talk to me privately if you need examples or browse
> > changelogs of later 5.6 releases.
> >
> > A twin brother of this is in 7.0 where there are just integer overflows
> > in string size calculations. Usually that requires huge strings as
> > inputs, so also requires running with no memory limit.
> >
> > These bugs are now treated as security issues,
>
> My main concern is not to know if we treat this bugs as security or not.
>
> It is mainly about "classification", and I think "low" risk bugs should
> be fixed using the normal bug process (going in a RC versions) rather
> than a specific process (fixed only at GA time), which should be
> reserved for higher risk bugs.
>
>
> Remi
>
>
>
I agree with Remi, these should be fixed via the normal development process
so we can catch any issues during the RC.
These are basically the same issue, they can be exploited the same way
(which I agree that has a low Exploitability) so we don't really gain much
by keeping them until the final release but we risk a lot from skipping the
general QA process.


--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--089e013d0f1a27a3a1053fee94f6--