ANNOUNCE: Zope 2.6.3 Release and Security Update
Zope 2.6.3 Release and Security Update Zope 2.6.3 contains a number of security related fixes for issues resolved during a comprehensive security audit conducted in Q4 2003. You may download Zope 2.6.3 from Zope.org: http://www.zope.org/Products/Zope/2.6.3/ **Users of the VerboseSecurity add-on product for Zope please note:** some of the security-related changes in Zope 2.6.3 are incompatible with the VerboseSecurity product. Please uninstall the VerboseSecurity product before upgrading to 2.6.3 to avoid problems. It is expected that VerboseSecurity will be updated to be compatible with Zope 2.6.3 in the near future. Also note that there are binary code changes in the 2.6.3 release, making it impossible to issue an external "hotfix" to resolve these issues. CVS users should be sure to update their sites **and rebuild the C Python extensions** to ensure that all fixes are deployed. In the fourth quarter of 2003, a comprehensive evaluation of the changes to Python from version 2.1 to 2.3.3 was undertaken. This evaluation was designed to assess each change to the Python environment in terms of its potential impact on the Zope application server and Zope applications, with the goal of making Python 2.3.3 the required Python platform for Zope beginning with Zope 2.7. The evaluation was focused on assessing changes to Python in the following contexts: - Changes that would have compatibility or other effects on existing or new Zope applications - Changes that could potentially affect the Zope security architecture or change the behavior of the restricted execution environment used by Zope to run untrusted code In the course of the evaluation, very few of the Python changes in 2.3.3 directly affected the Zope security architecture or had impacts on the restricted execution model. However, a number of pre-existing potential issues were discovered and resolved in the course of the comprehensive security audit that was performed as a part of the Python upgrade evaluation. Zope 2.6.3 provides fixes for all of these issues. A description of each issue, who is affected and issue status is included below. For more information on what is new in this release, see the CHANGES.txt and HISTORY.txt files for the release: - http://www.zope.org/Products/Zope/2.6.3/CHANGES.txt - http://www.zope.org/Products/Zope/2.6.3/HISTORY.txt For more information on the available Zope releases, guidance for selecting the right distribution and installation instructions, please see: http://www.zope.org/Documentation/Misc/InstallingZope.html ISSUES RESOLVED BY Zope 2.6.3: - For loops, list comprehensions, and other iterations in untrusted code Issue Description Iteration over sequences could in some cases fail to check access to an object obtained from the sequence. Subsequent checks (such as for attributes access) of such an object would still be performed, but it should not have been possible to obtain the object in the first place. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - List and dictionary instance methods in untrusted code Issue Description List and dictionary instance methods such as the get method of dictionary objects were not security aware and could return an object without checking access to that object. Subsequent checks (such as for attributes access) of such an object would still be performed, but it should not have been possible to obtain the object in the first place. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Use of import as in untrusted code Issue Description Use of "import as" in Python scripts could potentially rebind names in ways that could be used to avoid appropriate security checks. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Use of min, max, enumerate, iter, and sum in untrusted code Issue Description A number of newer built-ins were either unavailable in untrusted code or did not perform adequate security checking. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Broken binding validation in untrusted code Issue Description The variables bound to page templates and Python scripts such as "context" and "container" were not checked adequately, allowing a script to potentially access those objects without ensuring the necessary permissions on the part of the executing user. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Unpacking in untrusted code Issue Description Unpacking via function calls, variable assignment, exception variables and other contexts did not perform adequate security checks, potentially allowing access to objects that should have been protected. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Unicode passed to RESPONSE.write() could shutdown process Issue Description Inadequate type checking could allow unicode values passed to RESPONSE.write() to be passed into deeper layers of asyncore, where an exception would eventually be generated at a level that would cause the Zserver main loop to terminate. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - PythonScript class security not initialized properly Issue Description Class security was not properly intialized for PythonScripts, potentially allowing access to variables that should be protected. It turned out that most of the security assertions were in fact activated as a side effect of other code, but this fix is still appropriate to ensure that all security declarations are properly applied. Who Is Affected? Sites that use Python Scripts. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - XML-RPC instance marshaling may disclose protected values Issue Description XML-RPC marshalling of class instances used the instance __dict__ to marshal the object, and could include attributes prefixed with an underscore name. These attributes are considered private in Zope and should generally not be disclosed. Who Is Affected? All Zope sites. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - DTML tag dtml-tree may allow DoS attack Issue Description The dtml-tree tag used an "eval" of user-supplied data; its efforts to prevent abuse were ineffective. Who Is Affected? All Zope sites. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Potential cross-site scripting problem in default ZSearch interface Issue Description Browsers that do not escape html in query strings such as Internet Explorer 5.5 could potentially send a script tag in a query string to the ZSearch interface for cross-site scripting. Who Is Affected? Sites that use the default ZSearch interface. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Proxy rights on DTMLMethods transferred via acquisition Issue Description DTMLMethods with proxy rights could incorrectly transfer those rights via acquisition when traversing to a parent object. Who Is Affected? Sites that allow users who have increased permissions in subfolders to write DTMLMethods. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Improper security assertions on DTMLDocument objects Issue Description Some improper security assertions on DTMLDocument objects could potentially allow access to members that should be protected. Who Is Affected? Sites that use DTMLDocuments for secure content. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - PropertyManager 'lines' and 'tokens' properties stored as list Issue Description Some property types were stored in a mutable data type (list) which could potentially allow untrusted code to effect changes on those properties without going through appropriate security checks in particular scenarios. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Inadequate security assertions on admin "find" functions Issue Description Inadequate security assertions on administrative "find" methods could potentially be abused. Who Is Affected? All Zope sites. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - ZTUtils.SimpleTree state handling Issue Description The ZTUtils SimpleTree decompressed tree state data from the request without checking for final size, which could allow for certain types of DoS attacks. Who Is Affected? Sites that rely on the ZTUtils.SimpleTree. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Configuration file did not override security policy selection Issue Description This is not really a security issue, just a usability issue. It has always been possible to alternate between C and Python implemenations of the Zope security policy using certain environment variables. As of Zope 2.7, use of environment variables is deprecated in favor of the new 2.7 configuration files. The new configuration machinery was not implementing the directive used to override the default security policy. Who Is Affected? Zope 2.7 beta users. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher.
Brian -- Does this mean that Zope 2.6.3 is compatible with Python 2.3.3? I would be nice to retire 2.1.3. -dra On Thu, 8 Jan 2004, Brian Lloyd wrote:
Zope 2.6.3 Release and Security Update
Zope 2.6.3 contains a number of security related fixes for issues resolved during a comprehensive security audit conducted in Q4 2003. You may download Zope 2.6.3 from Zope.org:
[...]
On Thu, 2004-01-08 at 20:31, Dennis Allison wrote:
Does this mean that Zope 2.6.3 is compatible with Python 2.3.3? I would be nice to retire 2.1.3.
I'm not aware of any Zope Corp internal projects still using Python 2.1.3. I'm not aware of any serious incompatibilities. I suppose the only risk would be that fixing problems in Zope 2.6 specific to a Python version would have low priority because Zope 2.7 is on the horizon. Jeremy (not speaking for ZC)
Dennis Allison wrote:
Does this mean that Zope 2.6.3 is compatible with Python 2.3.3? I would be nice to retire 2.1.3.
A significant part of the effort for 2.6.3 (which was a backport from the original 2.7 work) lay in ensuring that the issues were fixed under all three Pythons (2.1.3, 2.2.3, 2.3.3). While we won't change the "officially supported" Python at this point in the 2.6 release cycle, you should know that our own projects have been running 2.6.x on 2.2.3 since at least June. After this effort, I have no reservations about recommending that those same customers begin evaluating the use of 2.3.3 for their 2.6-based Zope sites. In addition, we have a major support customer who *must* upgrade to Python 2.3.3, in order to allow Data.fs on Windows to grow beyond 2 Gb; they are not, however, ready to upgrade Zope (yet) to 2.7. We therefor have incentive to fix at least *major* issues related to running 2.6.3 under Python 2.3.3 (cosmetics are a different story, of course). Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
Glad to hear the news. I tried using Python 2.2 and 2.3 with Zope 2.6.2b3 with little success in the early Fall without success--but the many problems were RH9 related. We've since gone back to RH7.3 (the last stable RH release in my book) and used Python 2.1.3 for Zope (and Python 2.3.3 for everything else except RedHat tools). On Thu, 8 Jan 2004, Tres Seaver wrote:
Dennis Allison wrote:
Does this mean that Zope 2.6.3 is compatible with Python 2.3.3? I would be nice to retire 2.1.3.
A significant part of the effort for 2.6.3 (which was a backport from the original 2.7 work) lay in ensuring that the issues were fixed under all three Pythons (2.1.3, 2.2.3, 2.3.3). While we won't change the "officially supported" Python at this point in the 2.6 release cycle, you should know that our own projects have been running 2.6.x on 2.2.3 since at least June. After this effort, I have no reservations about recommending that those same customers begin evaluating the use of 2.3.3 for their 2.6-based Zope sites.
In addition, we have a major support customer who *must* upgrade to Python 2.3.3, in order to allow Data.fs on Windows to grow beyond 2 Gb; they are not, however, ready to upgrade Zope (yet) to 2.7. We therefor have incentive to fix at least *major* issues related to running 2.6.3 under Python 2.3.3 (cosmetics are a different story, of course).
Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
Dennis Allison wrote:
Glad to hear the news. I tried using Python 2.2 and 2.3 with Zope 2.6.2b3 with little success in the early Fall without success--but the many problems were RH9 related. We've since gone back to RH7.3 (the last stable RH release in my book) and used Python 2.1.3 for Zope (and Python 2.3.3 for everything else except RedHat tools).
RH9 has been rock solid for us, given two choices we made: - *Never*, *ever* run Zope in production with the OS's version of Python: it *won't* be built optimized for Zope, and it *will* change unexpectedly (from the perspective of the appserver developer). The SA will feel free to change the OS Python, including adding potentially destabilizing extensions, or *upgrading* it, and will be unrepentant when you (the appserver developer) complain that he broke your Zope. - *Run*, don't walk to get access to the updated kernel and glibc; the kernel, in particular, which RH9 installs out of the box is pathetically useless for running a memory-hungry appserver. We have found both yum and the apt-rpm port useful for keeping servers up to date. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
Tried to do the former, but Python 2.3.1 would not build on RH9 with significant brain surgery. Updated RH9 to the bleeding edge and got things mostly working except for some subsystems adn supporting systems which use threading and would not work under the new threading model without significant rework. Hence the decision to revert to RH7.3. Eventually we plan to move to a Gentoo system--I've been experimenting with Gentoo and have found it to be fairly easy to construct a customized, fast, and clean system although the time-to-build can be daunting. After some more testing I plan to move to Gentoo for production, a move motivated by the bad experience I've had with RH9 and RedHat's new business focus on the enterprise. One point of information, Tres. Was your positive experience over a range of machines. We've pretty much standardized on dual processor Athlon machines, 4GB memories, and hardware raid controllers in a RAID-10 configuration. It's possible that our problems with RH9 may be tied to some problem with their Athlon SMP systems. Thanks for your comments and advise. On Thu, 8 Jan 2004, Tres Seaver wrote:
Dennis Allison wrote:
Glad to hear the news. I tried using Python 2.2 and 2.3 with Zope 2.6.2b3 with little success in the early Fall without success--but the many problems were RH9 related. We've since gone back to RH7.3 (the last stable RH release in my book) and used Python 2.1.3 for Zope (and Python 2.3.3 for everything else except RedHat tools).
RH9 has been rock solid for us, given two choices we made:
- *Never*, *ever* run Zope in production with the OS's version of Python: it *won't* be built optimized for Zope, and it *will* change unexpectedly (from the perspective of the appserver developer). The SA will feel free to change the OS Python, including adding potentially destabilizing extensions, or *upgrading* it, and will be unrepentant when you (the appserver developer) complain that he broke your Zope.
- *Run*, don't walk to get access to the updated kernel and glibc; the kernel, in particular, which RH9 installs out of the box is pathetically useless for running a memory-hungry appserver. We have found both yum and the apt-rpm port useful for keeping servers up to date.
Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Dennis Allison wrote:
Tried to do the former, but Python 2.3.1 would not build on RH9 with significant brain surgery. Updated RH9 to the bleeding edge and got things mostly working except for some subsystems adn supporting systems which use threading and would not work under the new threading model without significant rework. Hence the decision to revert to RH7.3. Eventually we plan to move to a Gentoo system--I've been experimenting with Gentoo and have found it to be fairly easy to construct a customized, fast, and clean system although the time-to-build can be daunting. After some more testing I plan to move to Gentoo for production, a move motivated by the bad experience I've had with RH9 and RedHat's new business focus on the enterprise.
I am tracking Whitebox Linux (http://www.whiteboxlinux.org) at the moment: it is a "rebuild-RHEL-3-from-SRPM-under-RH-trademark-policy" distro, which seems to have decent momentum (updates flow through quickly, for instance).
One point of information, Tres. Was your positive experience over a range of machines. We've pretty much standardized on dual processor Athlon machines, 4GB memories, and hardware raid controllers in a RAID-10 configuration. It's possible that our problems with RH9 may be tied to some problem with their Athlon SMP systems.
Hmm, good point; we are using Dell's datacenter-class boxen, which are all Intel hardware. Our experiences with Athlon-based boxes were less happy, even under 7.3: we attributed the problems to the fact that they were "homebrew" hardware, rather than to problems with RH Athlon kernels. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
I have to agree with the recommendations of never running Zope with the OS Python. In fact, I usually don't even get it to work, since the OS Python have a tendency to not include modules included in the standard Python distribution, or behave weridly in some other way. For example, OpenBSD's standard binary Python used to barf on py files with Windows line endings, a big problem if you run a mixed environment. As to discussions in what OS to run, I can only say: OpenBSD. Very secure, dead easy to install and a very nice "source code" package delivery system in addition to the binary package distributions, removing the need to wait for the package to be recompiled by the package manager for your version of OpenBSD. Happily and securely runs several Zope servers even on old puny machines. :-) It doesn't work well as a client though, but as a server, I have yet to find anything to beat it. Well, maybe VMS was slightly better. :-) //Lennart
participants (5)
-
Brian Lloyd -
Dennis Allison -
Jeremy Hylton -
Lennart Regebro -
Tres Seaver