Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96595
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: 
Date: Mon, 24 Oct 2016 16:02:10 +0200
Message-ID: <018b01d22dff$389d9ed0$a9d8dc70$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQGoROuhyhG09wpdFsCUAeRJuSqPfQCv8xwnoQXzzWA=
Content-Language: en-us
Subject: RE: [PHP-DEV] bug classification discussion
From: anatol.php@belski.net ("Anatol Belski")



> -----Original Message-----
> From: Anatol Belski [mailto:anatol.php@belski.net]
> Sent: Monday, October 24, 2016 3:45 PM
> To: 'Stanislav Malyshev' <smalyshev@gmail.com>; 'PHP Internals'
> <internals@lists.php.net>
> Cc: 'Remi Collet' <remi@fedoraproject.org>
> Subject: RE: [PHP-DEV] bug classification discussion
>=20
> Hi Stas,
>=20
> > -----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
> >
> > 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'd like to hear feedback on this, especially - though definitely =
not
> > only! - from RMs and distro people.
> >
> > 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.
> >
> > Would be glad to hear some discussion on this.
>=20
> 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
>=20
> https://access.redhat.com/security/updates/classification
>=20
> While every case can of course have individual impacts, having a =
classification
> that covers some big part is IMO a clear way to go.
>=20
> For example, correlating the linked doc, with a bit modification:
>=20
> 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.
>=20
> 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.
>=20
Btw to low I'd add also

- scripts that are coded insecure way (fe accepting direct _GET/_POST =
data)
- bugs caused by the dependency libraries, unless in mandatory =
extensions or defined specifically otherwise
- bugs caused by incorrect API usage in non core extensions (fe passing =
NULL to internal core function, that expects an allocated var)

Regards

Anatol