bug classification discussion View as Markdown

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

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.

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.

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.

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

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

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

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.

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.

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.

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.

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

Le 24/10/2016 à 07:23, Stanislav Malyshev a écrit :

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,

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

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