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
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
