Jamie Heilman wrote:
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... 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