[Zope-dev] Re: vulnerability in zope 2.10.4

[Martin Aspeli]

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