DefaultPublishTraverse doesn't check for docstring on acquired methods

Bug #713253 reported by David Glick on 2011-02-04
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Zope 2
Fix Released
Tres Seaver

Bug Description

While investigating the Plone vulnerability which will be patched next Tuesday, the Plone security team also became aware of a security issue in the ZPublisher affecting Zope 2.10 and greater.

ZPublisher.BaseRequest.DefaultPublishTraverse.publishTraverse contains a check to make sure that the traversed object has a docstring. Objects without a docstring are Forbidden (unless they were found by view lookup). However, there is a path through publishTraverse where this check is not performed, if the traversed object was found as an acquired attribute.

This means that if a method without security declarations is reached as foo/bar/callMe (where callMe is acquired from foo, and bar is acquired from some parent of foo), the method will be published even if it has no docstring. As an example exploit, in Plone the SearchableText index can be cleared from the catalog by hitting path/to/Plone/portal_catalog/Plone/clearIndex?name=SearchableText as an unauthenticated user.

I am attaching a patch against Zope 2.12 which fixes the issue by ensuring the docstring check takes place for acquired objects as well. There is a risk of this breaking code that relies on being able to redirect to an unprotected, undocstringed acquired method, but IMHO dealing with the security risk should take precedence over that concern. FWIW, I've been running this patch on a number of Plone sites for the past week and haven't identified any problems stemming from the patch.

The fix can't easily be applied as a hotfix (it would require monkeypatching DefaultPublishTraverse.publishTraverse AFAICT), so it would be nice to have new releases in the 2.10, 2.11, 2.12, and 2.13 series incorporating the fix.

Tres Seaver (tseaver) on 2011-02-04
Changed in zope2:
assignee: nobody → Tres Seaver (tseaver)
status: New → Confirmed
Tres Seaver (tseaver) wrote :

This patch adds a tests which fails without David's fix, and succeeds with it.


Has anyone got a CVE for this yet? I can ask for one, but it will take a few days.


Changed in zope2:
milestone: none → 2.12.15
status: Confirmed → Fix Released
visibility: private → public
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers