Andreas Zeidler wrote:

hi,

imho i've found a vulnerability in zope 2.10.4 or rather in the newer version of five (1.5.5) used by it. in `Five/browser/ pagetemplatefile.py` in line 27 `createTrustedZopeEngine` is used the instantiate the page template engine used by five templates, or at least this is what i think it does. the problem with this is that `trustedBoboAwareZopeTraverse` (in `PageTemplates/Expressions.py`) gets used to traverse path-expressions using `unrestrictedTraverse` (line 100), which means that i can access say the title of an otherwise private object with a simple "obj/Title".

i ran into this when one of my doctests[1] failed after upgrading from zope 2.10.3 to 2.10.4, because it could now access the title, even though permissions are explicitly set up beforehand to prevent this. using `createZopeEngine` instead of `createTrustedZopeEngine` didn't help with the test, unfortunately, since this would then raise an `Unauthorized` right away when rendering the `folder_contents` view. however, if i defer resetting the roles of the test user to just before the "click" on 'Delete' (line 35 in the test), the test works again...

i've also just verified this ttw by creating a simple five view and a "file" object. i can successfully access the "title" attribute using the view, even though "view" and "access contents information" permissions are set up so only the "manager" role can access the object. dropping in zope 2.10.3 things work as expected, that is an `Unauthorized` exception is raised.

so, unless i'm completely wrong here, i'd say this is a pretty serious security whole, no?

I'd say "no". I believe this came from http://article.gmane.org/gmane.comp.web.zope.z3base.five/2225, and I believe it's a legitimate bugfix. Basically, I'd argue that .pt files for Five views are no less filesystem code than the .py files that house a view class. Previously, we had a weird situation where you got restrictedTraverse-like functionality using TALES (tal:replace='obj/attr') but not using python: expressions (tal:replace='python:obj.attr'). I have code which looks significantly funny or jumps through security hoops (arguably exposing too much information in the process) to deal with this bug (which is what I'd call it), and I'm really glad it's fixed. :) Obviously, this may be a problem for five.customerize, which needs to be more restrictive. I suspect five.customerize would've had a "security hole" with python: expressions, though. In any case, five.customerize is surely the exception here: The boundary between trusted and untrusted code has always been filesystem vs. TTW-editable. In general, this is only a security problem if: (a) a view is registered "too loosely" e.g. for * and could thus be used to inspect or modify objects that it wasn't really designed to deal with and (b) a view is registered for "too liberal" a permission; i.e. the permission to invoke the view is more widely available than the permission to access the attribute that the view is accessing on its context Even then, I think this is security-through-obscurity. If the variable in question was prepared/processed via python code in a view class, it'd never have been protected. In fact, if it was output using a python: expression rather than TALES, it would never have been protected. Martin -- Acquisition is a jealous mistress