> -----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 > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
