RE: [PHP-DEV] bug classification discussion

[Anatol Belski]

Hi,

> -Original Message-
> From: jakub@gmail.com [mailto:jakub@gmail.com] On Behalf Of Jakub
> Zelenka
> Sent: Wednesday, November 2, 2016 8:36 PM
> To: Stanislav Malyshev <smalys...@gmail.com>
> Cc: PHP Internals <internals@lists.php.net>; Remi Collet
> <r...@fedoraproject.org>
> Subject: Re: [PHP-DEV] bug classification discussion
> 
> Hi,
> 
> On Mon, Oct 24, 2016 at 6:23 AM, Stanislav Malyshev <smalys...@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.
> 
It looks, like there's the consensus on https://wiki.php.net/security in its 
current form, so probably no additional measures like voting are needed. Given 
that, I would suggest these classifications to officially become effective, so 
we start to apply them already for the subsequent releases. Are there any 
objections?

Thanks

Anatol




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bug classification discussion

[Jakub Zelenka]

Hi,

On Mon, Oct 24, 2016 at 6:23 AM, Stanislav Malyshev 
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

Re: [PHP-DEV] bug classification discussion

[Yasuo Ohgaki]

Hi Stas,

On Sun, Oct 30, 2016 at 2:21 PM, Stanislav Malyshev  wrote:
> So I wrote a first version of the document Anatol mentioned:
>
> https://wiki.php.net/security
>
> Please comment. Fixes to the grammar and typos are especially welcome
> (you can just do them in the wiki without asking :)

Nice work!
Reasonable content.

It may better to include Q for open_basedir that bypassing
open_basedir restrictions via module features are not considered as
security bugs. open_basedir restriction is to mitigate impact on
unwanted PHP code execution, not a complete solution.

We have "security bug" in document also. It may be better to mention
them and encourage users to report this kind of bug also.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] bug classification discussion

[Anatol Belski]

Hi Stas,

> -Original Message-
> From: Stanislav Malyshev [mailto:smalys...@gmail.com]
> Sent: Tuesday, November 1, 2016 6:14 PM
> To: Nikita Popov <nikita@gmail.com>
> Cc: Anatol Belski <anatol@belski.net>; PHP Internals
> <internals@lists.php.net>; Remi Collet <r...@fedoraproject.org>
> Subject: Re: [PHP-DEV] bug classification discussion
> 
> Hi!
> 
> > I'm also wondering under which category unserialize() issues would
> > (usually) fall. I'd assume "low" (because requires documented insecure
> > code + well known class of vulnerabilities).
> 
> I'd say medium. While it's documented that unserializing external strings is
> unsafe, there is code out there that does exactly that.
> Especially older code from times before JSON was mainstream.
> 
I can do that.

Regards

Anatol


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bug classification discussion

[Stanislav Malyshev]

Hi!

> Yet one thing seems to be missing - security issue, that only
> concerns an unstable branch. Those are probably can be handled as low
> severity, as any pre GA or master are not for production anyway.
> Still they should not be disclosed until fixed, but should be fine to
> fix at any point of time.

Makes sense. Please feel free to add, or I'll add it a bit later.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bug classification discussion

[Stanislav Malyshev]

Hi!

> I'm also wondering under which category unserialize() issues would
> (usually) fall. I'd assume "low" (because requires documented insecure
> code + well known class of vulnerabilities).

I'd say medium. While it's documented that unserializing external
strings is unsafe, there is code out there that does exactly that.
Especially older code from times before JSON was mainstream.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] bug classification discussion

[Anatol Belski]

> -Original Message-
> From: Nikita Popov [mailto:nikita@gmail.com]
> Sent: Tuesday, November 1, 2016 10:32 AM
> To: Stanislav Malyshev <smalys...@gmail.com>
> Cc: Anatol Belski <anatol@belski.net>; PHP Internals
> <internals@lists.php.net>; Remi Collet <r...@fedoraproject.org>
> Subject: Re: [PHP-DEV] bug classification discussion
> 
> On Sun, Oct 30, 2016 at 6:21 AM, Stanislav Malyshev <smalys...@gmail.com>
> wrote:
> 
> > Hi!
> >
> > So I wrote a first version of the document Anatol mentioned:
> >
> > https://wiki.php.net/security
> >
> > Please comment. Fixes to the grammar and typos are especially welcome
> > (you can just do them in the wiki without asking :)
> >
> 
> It would be nice to add specific examples (e.g. the string overflow case to 
> low).
> 
> I'm also wondering under which category unserialize() issues would
> (usually) fall. I'd assume "low" (because requires documented insecure code
> + well known class of vulnerabilities).
> 
Yet one thing seems to be missing - security issue, that only concerns an 
unstable branch. Those are probably can be handled as low severity, as any pre 
GA or master are not for production anyway. Still they should not be disclosed 
until fixed, but should be fine to fix at any point of time.

Regards

Anatol


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bug classification discussion

[Nikita Popov]

On Sun, Oct 30, 2016 at 6:21 AM, Stanislav Malyshev 
wrote:

> Hi!
>
> So I wrote a first version of the document Anatol mentioned:
>
> https://wiki.php.net/security
>
> Please comment. Fixes to the grammar and typos are especially welcome
> (you can just do them in the wiki without asking :)
>

It would be nice to add specific examples (e.g. the string overflow case to
low).

I'm also wondering under which category unserialize() issues would
(usually) fall. I'd assume "low" (because requires documented insecure code
+ well known class of vulnerabilities).

Nikita

Re: [PHP-DEV] bug classification discussion

[Joe Watkins]

Morning,

I did review and reformat the document, so that we have lists ... lists
of things are easier to retain in memory than paragraphs of things :)

Feel free to review the review.

Cheers
Joe

On Tue, Nov 1, 2016 at 1:47 AM, Anatol Belski <anatol@belski.net> wrote:

> Hi Stas,
>
> > -Original Message-
> > From: Stanislav Malyshev [mailto:smalys...@gmail.com]
> > Sent: Sunday, October 30, 2016 6:21 AM
> > To: Anatol Belski <anatol@belski.net>; 'PHP Internals'
> > <internals@lists.php.net>
> > Cc: 'Remi Collet' <r...@fedoraproject.org>
> > Subject: Re: [PHP-DEV] bug classification discussion
> >
> > Hi!
> >
> > So I wrote a first version of the document Anatol mentioned:
> >
> > https://wiki.php.net/security
> >
> > Please comment. Fixes to the grammar and typos are especially welcome
> (you
> > can just do them in the wiki without asking :)
> >
> I couldn't catch any syntax/grammar mistakes, and the sense is good AFM.
> I'd suggest to link this page on bugs.php.net and maybe elsewhere like in
> the manual, as a guidelines for security bug reporting.
>
> Regards
>
> Anatol
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

RE: [PHP-DEV] bug classification discussion

[Anatol Belski]

Hi Stas,

> -Original Message-
> From: Stanislav Malyshev [mailto:smalys...@gmail.com]
> Sent: Sunday, October 30, 2016 6:21 AM
> To: Anatol Belski <anatol@belski.net>; 'PHP Internals'
> <internals@lists.php.net>
> Cc: 'Remi Collet' <r...@fedoraproject.org>
> Subject: Re: [PHP-DEV] bug classification discussion
> 
> Hi!
> 
> So I wrote a first version of the document Anatol mentioned:
> 
> https://wiki.php.net/security
> 
> Please comment. Fixes to the grammar and typos are especially welcome (you
> can just do them in the wiki without asking :)
> 
I couldn't catch any syntax/grammar mistakes, and the sense is good AFM. I'd 
suggest to link this page on bugs.php.net and maybe elsewhere like in the 
manual, as a guidelines for security bug reporting.

Regards

Anatol


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bug classification discussion

[Stanislav Malyshev]

Hi!

So I wrote a first version of the document Anatol mentioned:

https://wiki.php.net/security

Please comment. Fixes to the grammar and typos are especially welcome
(you can just do them in the wiki without asking :)

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bug classification discussion

[Pierre Joye]

Hi,

On Oct 28, 2016 10:33 PM, "Ferenc Kovacs"  wrote:
>
> On Fri, Oct 28, 2016 at 11:18 AM, Remi Collet 
> wrote:
>
> > 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
> >
> >
> >
> 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.

Thanks Stas for bringing that up.

It is indeed a case by case decision, however I fully agree with Remi and
Tyrael here, for the cases described by Stas initial post (or similar).

It is extremely hard to do it in a short time during final phases, let
alone the risk to create more damages by applying a bad fix.

About marking them as low security bugs or not. I have no strong opinion.
Maybe we could define what is a production environment and then define bugs
affecting this environment as security issues.

Cheers
Pierre

Re: [PHP-DEV] bug classification discussion

[Ferenc Kovacs]

On Fri, Oct 28, 2016 at 11:18 AM, Remi Collet 
wrote:

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


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] bug classification discussion

[Joe Watkins]

Morning,

Trying to re-shape our own classification system seems like a good idea.

I have no good idea of how to write such a document, would be happy to
review (and make other people review) if someone were to start.

Cheers
Joe

On Fri, Oct 28, 2016 at 10:18 AM, Remi Collet 
wrote:

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

Re: [PHP-DEV] bug classification discussion

[Remi Collet]

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




signature.asc
Description: OpenPGP digital signature

RE: [PHP-DEV] bug classification discussion

[Anatol Belski]

> -Original Message-
> From: Anatol Belski [mailto:anatol@belski.net]
> Sent: Monday, October 24, 2016 3:45 PM
> To: 'Stanislav Malyshev' <smalys...@gmail.com>; 'PHP Internals'
> <internals@lists.php.net>
> Cc: 'Remi Collet' <r...@fedoraproject.org>
> Subject: RE: [PHP-DEV] bug classification discussion
> 
> Hi Stas,
> 
> > -Original Message-
> > From: Stanislav Malyshev [mailto:smalys...@gmail.com]
> > Sent: Monday, October 24, 2016 7:23 AM
> > To: PHP Internals <internals@lists.php.net>
> > Cc: Remi Collet <r...@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
> p

RE: [PHP-DEV] bug classification discussion

[Anatol Belski]

Hi Stas,

> -Original Message-
> From: Stanislav Malyshev [mailto:smalys...@gmail.com]
> Sent: Monday, October 24, 2016 7:23 AM
> To: PHP Internals <internals@lists.php.net>
> Cc: Remi Collet <r...@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




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] bug classification discussion

[Stanislav Malyshev]

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.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php