Tooling through restructuring of my site I discovered a stupid
permissions problem.  While App.Permission declares the 'Define
permission' perm it never gets initialized and thus
manage_addPermission{,Form} basically had weakened security.  The
permission 'Access contents information' was still protecting the
method, but thats not adequate--that permission was never intented
(afaik) to represent "write access" to the zodb.  By default, as the
'Access contents information' permission is granted to the Anonymous
user, anybody could fire off a request to
http://victimhost/Control_Panel/Products/x/manage_addPermission?id=foo&title=bar
where 'x' is some installed product (hey, why not use the HelpSys vuln
to find one that fits your fancy!) to add a permission object to
Product x.  Anonymous users being allowed to bloat the zodb at the
least, possibly other issues at the worst (I don't know, I don't use
the ZClass machinery).

A quick refactor of App/Permission.py may be found at
http://audible.transient.net/zope/Permission.py which protects the
methods in question, however I have a hunch there may be more broken
here than this permission alone.

Testimonies on #zope indicate this affects 2.6.x as well as CVS, I
don't know how far back the bug goes (only due to sheer lazyness).

Collector report will be filed shortly, expect it to be hidden.

Workarounds: use the above Permission.py, or remove 'Access contents
information' from the Control_Panel/Products folder (and possibly
others)

-- 
Jamie Heilman                   http://audible.transient.net/~jamie/
"It's almost impossible to overestimate the unimportance of most things."
                                                        -John Logue

_______________________________________________
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Reply via email to