Matthew et al, There are three key issues.
1. How do security vulnerabilities get disclosed to Zend. Especially serious ones that a vendor should know about before the public.
2. What will Zend do to ensure the bug is verified, fixed and patched. 3. How will Zend distribute those patches. Possible solutions 1. We need a well publicized security contact point.2. Zend needs to spin up a zf-security team to deal with issues in a timely fashion.
3. This is where it gets tricky:So far, any bugs patched have been done so in the next version (usually a point release) just as any other bug would be. You'd have to be really on the ball to know whether or not you need to upgrade to the latest point release due to a vulnerability.
So I propose:That a USN page be setup to disclose security issues which require user intervention. (Like upgrading applications) That a fw-security-announce mailing list be setup to send emails about recently fixed security bugs.
Next,Lets talk about Zend_Tool, version specific packaging, patching, updating (backports) and the like.
My biggest concern is the availability of (or lack thereof) of security-only patch sets for old released versions. Eg if one wants to get security fixes for an application dependant on 1.0.0 -- they shouldn't have to upgrade their applications to 1.0.X or 1.5.X newer vers, as there are some compatibility problems in just upgrading. It's certainly not something a sysadmin could just do. There should ideally be something in Zend_Tool to automate the process of checking for security updates, and applying them to a specific framework version.
I'd also like to see a Zend_Security component that could check a webservice to see if the currently running framework has known vulnerabilities such that an application could be programed to shut down instead of running insecurely. This would be a huge feature to prevent the problems that have plagued other mainstream php projects.
I'm sure the community has lots more ideas of what they want to see from Zend on the security/change management front.
Kevin Matthew Weier O'Phinney wrote:
-- Kevin McArthur <[EMAIL PROTECTED]> wrote (on Tuesday, 10 June 2008, 12:31 PM -0700):No one's blaming anyone for the code, it's what the response is, and will be. Bugs will happen... but will backports? If you search the lists you'll find numerous attempts to get a security policy discussion started, and it never goes anywhere.So lets get somewhere already.How is the project going to respond to a validator that is letting tainted information into applications. Maybe Matthew, as architect, can respond on what Zend is doing to address this and other security disclosures with the framework?KevinP.S. Far from complaining without action, I've tried to get this subject addressed, proactively, numerous times. I've been critical of the SVN externals distribution, critical of attempts to get a Zend Framework 'package' released for Linux distributions, and I've always brought up security issues with the development team as I've found them. We need some leadership and responsibility from Zend on the security policy.Kevin, I've been on fw-general since day one, and I do not recall any serious or repeated attempts to discuss the subject. Admittedly, until the past six months, ZF was not my full-time job, and it may have slipped under the radar, but I'm sure I would recollect something this serious. As to our policy: get the issue fixed ASAP, and issue a point release. Patches are available via the repo browser, and we will likely post links and/or instructions on how to grab a patch or patched file. Response time will be based on the severity of the vulnerability, but the above is the policy. Regardless of severity, an issue is always entered in the tracker, to ensure that it is reported in our changelogs. I welcome you to email me directly with your concerns, or to start a new thread with them. I'm particularly curious what your concerns are regarding distro-specific packages. Regarding usage of svn:externals, this is an optional way to grab ZF, and I'm also curious what issues you see with it.Thomas Weidner wrote:I'm not the one to blame as I am not the author of Zend_Validate.But I think it's always better to write a issue regardless of what the type is set "new" or "improvement" or "bug" or "problem" or "whatever", than discussing here how the author meant his implementation.Maybe he made a problem in the api doc, maybe in his implementation. Only the author knows this.Related to your PS, this shows only that the author has not wrote the right unit tests. Because this is true for this particular component does not mean that it's true for the complete framework. But it's always easier to complain about the failures of others. I understand this. :-)Greetings Thomas Weidner, I18N Team Leader, Zend Framework http://www.thomasweidner.com ----- Original Message ----- From: "Kevin McArthur" <[EMAIL PROTECTED]> Cc: <fw-general@lists.zend.com> Sent: Tuesday, June 10, 2008 8:39 PM Subject: Re: [fw-general] Zend_Validate_IpIf invalid ip strings are confirmed as passing validation then this should not be logged as a 'new feature' request, but something handled by whomever is considered the security team these days -- probably with a quick point/patch release and a security advisory.The downstream implications of _any_ failing validator are very serious. I've not looked at this specific validator, but if its allowing extra string data into a valid context, it could lead to exploitable circumstances [sql injection, buffer overrun, etc]KevinP.S. This issue, again, underscores how the project does not have sufficient policy in place for security issues and patch distribution.Thomas Weidner wrote:Feel free to add a feature request to jira for thi new feature. http://framework.zend.com/issues/browse/ZF Greetings Thomas Weidner, I18N Team Leader, Zend Framework http://www.thomasweidner.com----- Original Message ----- From: "Joachim Knust" <[EMAIL PROTECTED]>To: <fw-general@lists.zend.com> Sent: Tuesday, June 10, 2008 5:44 PM Subject: [fw-general] Zend_Validate_IpHello!I'd like to use Zend_Validate_Ip to check if some input strings are - surprise - valid IP addresses. When I got some problems with strings like "192.168.34" or "192.168.34.234 asdf" which evaluated to true, I had a look into apidocs and found:"Returns true if and only if $value is a valid IP address"Both example strings are not valid IP address, in my oppinion. Internally ip2long is used to do the checking, which accepts a lot more than just "valid IP addresses".Is this intended behaviour or is it a bug and may change in the future?Regards -joachim knust-- Kevin McArthur StormTide Digital Studios Inc. Author of the recently published book, "Pro PHP" http://www.stormtide.ca-- Kevin McArthur StormTide Digital Studios Inc. Author of the recently published book, "Pro PHP" http://www.stormtide.ca
-- Kevin McArthur StormTide Digital Studios Inc. Author of the recently published book, "Pro PHP" http://www.stormtide.ca
smime.p7s
Description: S/MIME Cryptographic Signature
