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).
Ok, I've looked into this. I don't think there is a serious hole. The most people can do is add permission objects, but those permission objects have no real effect on security until someone maps them to a method. I'm going to check in a fix, but there's no need for a hotfix.
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.
Anything called manage_* is automatically restricted to ['Manager'] by default, as long as the class gets initialized. The problem, as you said, was that the class was never initialized.
Shane
_______________________________________________
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 )
