Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96592
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Stanislav Malyshev'" <smalyshev@gmail.com>,
	"'PHP Internals'" <internals@lists.php.net>
Cc: "'Remi Collet'" <remi@fedoraproject.org>
References: <1ae4bea0-d62b-fd61-f6b6-55762e97df6e@gmail.com>
In-Reply-To: <1ae4bea0-d62b-fd61-f6b6-55762e97df6e@gmail.com>
Date: Mon, 24 Oct 2016 15:44:48 +0200
Message-ID: <017b01d22dfc$cbead8e0$63c08aa0$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQGoROuhyhG09wpdFsCUAeRJuSqPfaELZTnA
Content-Language: en-us
Subject: RE: [PHP-DEV] bug classification discussion
From: anatol.php@belski.net ("Anatol Belski")

Hi Stas,

> -----Original Message-----
> From: Stanislav Malyshev [mailto:smalyshev@gmail.com]
> Sent: Monday, October 24, 2016 7:23 AM
> To: PHP Internals <internals@lists.php.net>
> Cc: Remi Collet <remi@fedoraproject.org>
> Subject: [PHP-DEV] bug classification discussion
>=20
> Hi!
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> I'd like to hear feedback on this, especially - though definitely not =
only! - from
> RMs and distro people.
>=20
> There are some libraries (ICU, I'm looking at you!) which have much =
lower limits
> and fixed buffers inside and unfortunately they don't enforce or check =
those
> limits, they just kind of assume everybody is nice. For those, I think =
we'd have to
> treat issues stemming from that as security issues if they look =
exploitable. Also,
> some libraries have int overflows independent of PHP (also needing =
huge strings
> to trigger) - not sure what to do with those.
>=20
> Would be glad to hear some discussion on this.

Thanks for bringing this up. I was looking through several docs in this =
regard, and IMHO it'd be indeed useful to have just clear definitions of =
security bugs. It could be possible to create a document, which would =
guide both reporters and maintainers to consider the exact metrics. As =
an example of such a classification, I would like to link the document =
below, while there are also other classifications possible and we for =
sure need to develop our own that fits the situations we have in PHP =
best

https://access.redhat.com/security/updates/classification

While every case can of course have individual impacts, having a =
classification that covers some big part is IMO a clear way to go.

For example, correlating the linked doc, with a bit modification:

High - vulnerability, that can be exploited by unauthenticated remote =
users, despite the highest possible secure server settings and is caused =
by PHP's internal bug or a certain way the script is programmed . Such a =
vulnerability would cause a serious damage like an unauthorized root =
access, data loss, confidentiality compromise, etc.=20

Moderate - vulnerability is hard to exploit and localized in some =
extension and doesn't affect any internal code in main, TSRM, Zend or =
mandatory extensions, but would still cause serious damages.=20

Low - vulnerability is hard to exploit or requires insecure PHP or =
system configuration.

It might make sense to start writing up such a document and extending it =
while having actual issues. Once we have such a definition, it could =
even go through an RFC and become a standard. This might indeed ease the =
equilibration between security and QA, thus to crystalize a better =
security issue handling process. IMHO, the security bugs with the low =
severity as from above, are fine to be merged already in RCs.

Regards

Anatol