Please, check if our versions are vulnerable too. We don't have 1.11.3 but...
@php, Bjarke, I am not able to find much information on this. Do you know if it is fixed in 1.11.10 added via 383539 or the current stable 1.11.6? Thanks.
From what I can read here: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3825 - the bug is related to 1.11.3 running in Zend Server. Since that is not how we use Zend Framework, I would guess that we are not hit by this problem. What do you guys think?
Bjarke, my fault. I've misunderstood Zend CE and Zend Server in Zend Framework. Sorry about this.
Security people, do you agree? If so, please close this bug.
(In reply to comment #4) > Security people, do you agree? > > If so, please close this bug. I'll need to rely on your expertise, but I see the Validate.php in the tarball we use: # pwd /var/tmp/portage/dev-php/ZendFramework-1.11.6/work/ZendFramework-1.11.6 # find . -name Validate.php ./library/Zend/Validate.php ./library/Zend/Service/DeveloperGarden/Request/SmsValidation/Validate.php # How did you determine we are not affected? Thanks!
Based on the summary of the CVE, where they state that Zend Framework 1.11.3 in Zend Server CE 5.1.0 is broken. I would say that it imply that when not used in Zend Server, it is not broken, wouldn't you?
I do not see any reason why we should not be vulnerable to this. I think the description want to say that the Zend Framework version bundled with Zend Server is vulnerable, not that ZF is vulnerable only when used together with ZSCE. Regarding the vulnerability itself, this is how I interpret it: Judging by the quote "[..] most web application authors assume path disclosure as server level/configuration issue [..]" found in the CVE references, the issue is about PHP outputting the path of uncaught exceptions when display_errors=On. That also makes sense based on the list of files with this vulnerability. Does this interpretation make sense?
That is also how I interpret it, but I don't see how to fix this, since it seems like more like php is broken by design if that feature is enabled :) I must admit, I haven't got an idea on how to fix it, since it is supposed to leak that if the display_errors is enabled?
(In reply to comment #8) > That is also how I interpret it, but I don't see how to fix this, since it > seems like more like php is broken by design if that feature is enabled :) > > I must admit, I haven't got an idea on how to fix it, since it is supposed to > leak that if the display_errors is enabled? I would side with the framework devs here. I see display_error=On as a debug/development setting. The documentation both in the config file itself and everywhere else state that you should not have this setting enabled in production. It is certainly not something that we should be involved in "fixing".
Alright, thank you. I completely agree, fwiw. Resolving as INVALID; please reopen if you disagree.