Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96710
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.43 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <1ae4bea0-d62b-fd61-f6b6-55762e97df6e@gmail.com>
References: <1ae4bea0-d62b-fd61-f6b6-55762e97df6e@gmail.com>
Date: Wed, 2 Nov 2016 19:36:13 +0000
Message-ID: <CAEKnhAF7_uH+ksei4d5uD8C1R1hOsAO_t76DCkd4RE0PWY0hsA@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP Internals <internals@lists.php.net>, Remi Collet <remi@fedoraproject.org>
Content-Type: multipart/alternative; boundary=001a11411a1ccb6a400540568d00
Subject: Re: [PHP-DEV] bug classification discussion
From: bukka@php.net (Jakub Zelenka)

--001a11411a1ccb6a400540568d00
Content-Type: text/plain; charset=UTF-8

Hi,

On Mon, Oct 24, 2016 at 6:23 AM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> 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 assume
> 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, due to the fact that in
> theory somebody might be running with no memory limit and get huge
> string as an input from user. However, it was questioned that we indeed
> should treat them so, due to the fact that encountering them in
> production is unlikely, and due to the fact that they require patching
> in many places, and merging those fixes out-of-band creates significant
> potential for bugs.
>
>
I would probably treat them as a low severity issues. It means just not
disclose them until they are fixed and let RM decide if they want to pull
them to the branches for security fixes only. The thing is that it might
take time till they are fixed so better not to keep them publicly visible.

Cheers

--001a11411a1ccb6a400540568d00--