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
