Date: Thu, 18 Jun 2015 11:02:00 +0200 From: Tomas Hoger <thoger@...hat.com> To: cve-assign@...re.org Cc: oss-security@...ts.openwall.com, kaplanlior@...il.com, security@....net Subject: Re: Re: CVE Request: various issues in PHP On Tue, 16 Jun 2015 13:24:56 -0400 (EDT) cve-assign@...re.org wrote: > In this type of situation, CVEs are assigned on a per-discoverer basis. > CVE-2015-4025 is for thoger@...hat.com discoveries, whereas > CVE-2015-4026 is for yohgaki@....net. See: > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4025 > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4026 > > > dir()/opendir() and chroot() > > Four weeks ago, we asked security@....net to contact us if those other > changed functions were associated with vulnerability fixes. They have > not contacted us about this. > > Are you reporting that some or all of them had vulnerabilities? With all these CVE-2006-7243-like issues, it's bit tricky. Many of those that got corrected recently seem rather unlikely to be used with untrusted inputs. However, if you think hard, you may be able to come up with some convoluted use case where they matter. So it may not be easy to draw the line between those that may still qualify as security fixes and those that don't. The recent approach was to handle them as security (e.g. upstream bugs were changed to security bugs and made private until they were fixed). > For example, is it reasonable to expect that a PHP application may > want the client to make a choice of a chroot directory, and the > intended behavior is to restrict the choice to a name ending in ".d" > but this can be bypassed by something like a > "/usr/local/var/x/does-not-end-in-dot-d\0.d" value? With chroot requiring root privileges, the function should not be used in typical PHP use cases at all. So the above example does not seem likely. > > More unserialize issues. > > > https://bugs.php.net/bug.php?id=69152 > > http://git.php.net/?p=php-src.git;a=commitdiff;h=51856a76f87ecb24fe1385342be43610fb6c86e4 > > Use CVE-2015-4599 for the taoguangchen@...oud.com discovery fixed in > 51856a76f87ecb24fe1385342be43610fb6c86e4. > > > > http://git.php.net/?p=php-src.git;a=commitdiff;h=0c136a2abd49298b66acb0cad504f0f972f5bfe8 > > Use CVE-2015-4600 for the taoguangchen@...oud.com discoveries in bug > 69152 that were fixed in 0c136a2abd49298b66acb0cad504f0f972f5bfe8 - > SoapClient::__getLastRequest, SoapClient::__getLastResponse, > SoapClient::__getLastRequestHeaders, > SoapClient::__getLastResponseHeaders, SoapClient::__getCookies, and > SoapClient::__setCookie. > > Use CVE-2015-4601 for the other vulnerabilities fixed in > 0c136a2abd49298b66acb0cad504f0f972f5bfe8, with the exception that the > issue involving the uri property in do_soap_call is already covered by > CVE-2015-4148. > > > > http://git.php.net/?p=php-src.git;a=commitdiff;h=fb83c76deec58f1fab17c350f04c9f042e5977d1 > > Use CVE-2015-4602 for this issue mentioned at [2015-03-20 14:58 UTC] > in bug 69152. > > > > https://bugs.php.net/bug.php?id=69152 [2015-03-03 04:30 UTC] > > Use CVE-2015-4603 for the exception::getTraceAsString issue. As > mentioned at [2015-03-25 09:57 UTC], the affected versions for this > issue are different from those of other issues discussed in bug 69152. Out of curiosity, why all the splits here? E.g. CVE-2015-4599 and CVE-2015-4600 have same reporter, same type, same affected (released) versions, and the same PHP extension. I assume CVE-2015-4601 is separate because of different / unclear reporter. CVE-2015-4601 and CVE-2015-4602 seem like possible candidate for merging with CVE-2015-4599 / CVE-2015-4600 as they also have the same reporter and versions. There's benefit of having them separate as they don't affect SOAP extension, but issue affecting different module of the code base is not a typical reason for split. Thank you! -- Tomas Hoger / Red Hat Product Security
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ