Re: [Zope-dev] App.Permission security hole
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=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 )
[Zope-dev] App.Permission security hole
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 )
