Zope application server framework improperly handled certain exceptions in the code of PluggableAuthService (PAS). A remote, unauthenticated user could request / access a private page, resulting in unhandled exception to occur and Zope thread termination. Repetition of the attack scenario could allow an attacker to terminate all Zope child treads, leading to denial of service. References: [1] http://bugs.gentoo.org/show_bug.cgi?id=336317 [2] https://bugs.launchpad.net/zope2/+bug/627988 [3] http://secunia.com/advisories/41267/ [4] http://www.zope.org/Products/Zope/2.10.12/zope-2.10.12-released [5] http://www.zope.org/Products/Zope/2.11.7/zope-2.10.12-released Upstream changesets: a, against v2.10 branch: [6] http://svn.zope.org/Zope/branches/2.10/?rev=116087&view=rev b, against v2.11 branch: [7] http://svn.zope.org/Zope/branches/2.11/?rev=116088&view=rev
Public proof of concept (from [2]): ==================================== The easiest way to trigger this behaviour, is buildout. Create this buildout.cfg: [buildout] extends=http://svn.plone.org/svn/collective/buildout/plonetest/plone-3.3.5.cfg Get yourself a copy of bootstrap.py and run buildout. * Start Zope * Create a new Plone site * Add a new page, make it private. * Log out * As anonymous, manually craft the following URL: http://yoursite/plone/new_page?came_from:list=123
This issue affects the version of the zope package, as present within EPEL-5 repository. Please fix.
Statement: Not vulnerable. This issue did not affect the versions of conga as shipped with Red Hat Cluster Suite for Red Hat Enterprise Linux 4 and as shipped with Red Hat Enterprise Linux 5 as they use own internal mechanism to verify if user requesting particular page is authenticated. Plone private pages permissions configuration mechanism is not used in conga.
Created zope tracking bugs for this issue Affects: epel-5 [bug 772292]