I have a Zope server running with two instances of plone, "Plone1" and "Plone2". plone2 is a demo site with a user "Demo" having the role 'Manager' available to the public. plone1 is a regular plone site. If I log in to plone2 as the user Demo, then go to the following url: http://my.server/plone2/plone1 The permissions are acquired from the demo site giving full Manager access to my main plone site. This is obviously a serious problem. Any ideas how I can stop the permissions from being acquired under that situation without breaking anything? -James.
On Thu, 2003-03-27 at 01:39, jamesd@mena.org.au wrote:
If I log in to plone2 as the user Demo, then go to the following url: http://my.server/plone2/plone1 The permissions are acquired from the demo site giving full Manager access to my main plone site. This is obviously a serious problem.
Yep. This is a huge vulnerability in certain configurations. But the *real* problem is not that plone1 methods can be applied to plone2 objects. That is a feature, not a bug. :-) Rather, the problem is that you have implicitly *permitted* this to take place by using common roles across sites. I suspect that you're hardly alone in setting up your site this way. In fact, I was auditing one of my own sites and stumbled across a variant of this technique that allowed arbitrary access to virtually any object on the server. Yikes! I'm working on a howto for this concern... but in the interim, I'd strongly recommend taking three steps to secure *any* multi-user, multi-host Zope app: 1. Reserve the Manager role for server administration only. Just as importantly, don't *ever* assign a Manager proxy role unless you are certain you've worked out all the implications of that method being applied to arbitrary objects. 2. Use different roles for different groups of users. Create site-specific, function-specific roles like site1_admin, site2_admin, site1_user, etc. Use server-wide roles sparingly and define them narrowly (send_mail, add_user, etc). 3. Disable/restrict "view folder contents" permissions for all folders that are parents of your site root folders. Leaving that permission turned on for Anonymous (the default) allows virtually anyone to obtain details about your server setup that are quite handy for setting up cross-site scripting exploits. It's shockingly easy to do this and there are few (if any) reasons why you'd want that feature enabled for parents of your site roots anyway. HTH, Dylan
Having to create a new Manager and Reviewer role for each of the portals I host and setting it up to work correctly (considering checking for the role 'Manager' is hard coded in many places) would be an enormous task, so this is not feasable. Considering the exploit does not affect folders (going to plone2/portals/manage_main does not work, while plone2/plone1/manage_main does, where 'portals' is a folder) is there a way to force the permissions to be inherited from 'container' and not 'context'?
Yep. This is a huge vulnerability in certain configurations.
But the *real* problem is not that plone1 methods can be applied to plone2 objects. That is a feature, not a bug. :-)
Rather, the problem is that you have implicitly *permitted* this to take place by using common roles across sites. I suspect that you're hardly alone in setting up your site this way. In fact, I was auditing one of my own sites and stumbled across a variant of this technique that allowed arbitrary access to virtually any object on the server. Yikes!
I'm working on a howto for this concern... but in the interim, I'd strongly recommend taking three steps to secure *any* multi-user, multi-host Zope app:
1. Reserve the Manager role for server administration only. Just as importantly, don't *ever* assign a Manager proxy role unless you are certain you've worked out all the implications of that method being applied to arbitrary objects.
2. Use different roles for different groups of users. Create site-specific, function-specific roles like site1_admin, site2_admin, site1_user, etc. Use server-wide roles sparingly and define them narrowly (send_mail, add_user, etc).
3. Disable/restrict "view folder contents" permissions for all folders that are parents of your site root folders. Leaving that permission turned on for Anonymous (the default) allows virtually anyone to obtain details about your server setup that are quite handy for setting up cross-site scripting exploits. It's shockingly easy to do this and there are few (if any) reasons why you'd want that feature enabled for parents of your site roots anyway.
HTH,
Dylan
On Thu, 2003-03-27 at 04:27, jamesd@mena.org.au wrote:
Having to create a new Manager and Reviewer role for each of the portals I host and setting it up to work correctly (considering checking for the role 'Manager' is hard coded in many places) would be an enormous task, so this is not feasable.
That's unfortunate, since it's the only reliably secure way of setting up multi-user, multi-host services. The recommendation about restricting the display of folder contents is still pretty high value and can probably be done painlessly. Cross-site scripting exploits are far harder to perform once Zope stops giving away detailed information on what stuff is available where. It's not a complete fix, but it's a huge step in the right direction.
Considering the exploit does not affect folders (going to plone2/portals/manage_main does not work, while plone2/plone1/manage_main does, where 'portals' is a folder)
It would appear that you have restricted access to the portals folder. That's a good thing. But it has nothing to do with whether the attacked object is a folder or not. It is possible to call *any* method of plone1 on *any* object of plone2 or its parents. The degree to which such an attempt works is dependent on little more than how roles are configured. is there a way to force the permissions
to be inherited from 'container' and not 'context'?
That's already how it works. The problem you have is that the roles for both these sites are defined in the *same* container. Unless you define roles/users a bit deeper in the tree, how can Zope possibly know where/how roles ought to be partitioned? I can appreciate the effort that is probably involved in retrofitting sites with hard-coded roles... but if security is important to you, your best bet is to combine Zope's excellent security framework with general best practices in designing and implementing security schemes. HTH, Dylan
[Dylan Reinhardt wrote (zope@dylanreinhardt.com) on 3/26/03 2:33 PM]
On Thu, 2003-03-27 at 01:39, jamesd@mena.org.au wrote:
If I log in to plone2 as the user Demo, then go to the following url: http://my.server/plone2/plone1 The permissions are acquired from the demo site giving full Manager access to my main plone site. This is obviously a serious problem.
Yep. This is a huge vulnerability in certain configurations.
But the *real* problem is not that plone1 methods can be applied to plone2 objects. That is a feature, not a bug. :-)
(butting into this thread late) right, this is aquisition. if you have index_html in the same folder as standard_html_footer and do <dtml-var standard_html_footer> in your index_html, it pulls that one and not one above. Same idea with folders, right?
Rather, the problem is that you have implicitly *permitted* this to take place by using common roles across sites. I suspect that you're hardly alone in setting up your site this way. In fact, I was auditing one of my own sites and stumbled across a variant of this technique that allowed arbitrary access to virtually any object on the server. Yikes!
I'm not so sure its because of this...
I'm working on a howto for this concern... but in the interim, I'd strongly recommend taking three steps to secure *any* multi-user, multi-host Zope app:
1. Reserve the Manager role for server administration only. Just as importantly, don't *ever* assign a Manager proxy role unless you are certain you've worked out all the implications of that method being applied to arbitrary objects.
2. Use different roles for different groups of users. Create site-specific, function-specific roles like site1_admin, site2_admin, site1_user, etc. Use server-wide roles sparingly and define them narrowly (send_mail, add_user, etc).
I tested this out and found it did not work. I had two folders (folder1, folder2) side by side in the same container (folder). I gave a user in folder1 the role X_admin, which role had all the same perms as manager. this is the only role this user had. this user was still able to call folder1/folder2 and do what he liked in folder2.
3. Disable/restrict "view folder contents" permissions for all folders that are parents of your site root folders. Leaving that permission turned on for Anonymous (the default) allows virtually anyone to obtain details about your server setup that are quite handy for setting up cross-site scripting exploits. It's shockingly easy to do this and there are few (if any) reasons why you'd want that feature enabled for parents of your site roots anyway.
I don't see this permission anywhere... Do you mean "Access contents information" ? I would add that turning off WebDAV access for anonymous users is a good idea. <--> george donnelly - http://www.zettai.net/ - "We Love Newbies" :) Zope Hosting - Dynamic Website Design - Search Engine Promotion Yahoo, AIM: zettainet - MSN: zettainet@hotmail.com - ICQ: 51907738
george donnelly wrote:
I would add that turning off WebDAV access for anonymous users is a good idea.
http://collector.zope.org/Zope/790 Authenticated webdav will evidently be the default in 2.7, though I suppose that will only affect new installations. -- Jamie Heilman http://audible.transient.net/~jamie/ "It's almost impossible to overestimate the unimportance of most things." -John Logue
On Sat, 2003-03-29 at 15:35, george donnelly wrote:
In fact, I was auditing one of
my own sites and stumbled across a variant of this technique that allowed arbitrary access to virtually any object on the server. Yikes!
I'm not so sure its because of this...
What do you think it might be?
2. Use different roles for different groups of users. Create site-specific, function-specific roles like site1_admin, site2_admin, site1_user, etc. Use server-wide roles sparingly and define them narrowly (send_mail, add_user, etc).
I tested this out and found it did not work. I had two folders (folder1, folder2) side by side in the same container (folder). I gave a user in folder1 the role X_admin, which role had all the same perms as manager. this is the only role this user had. this user was still able to call folder1/folder2 and do what he liked in folder2.
I'm not sure if there's enough information to know what you're saying, exactly. That won't stop me from responding, though. :-) The roots of most virtual hosts are going to be viewable by Anonymous, as will much of their content. As such, those objects can be acquired at will by anyone. It's very difficult to prevent acquisition from allowing the *viewing* of objects cross-site since keeping these things viewable by Anonymous is pretty darn convenient. In many situations, it could be condidered a problem that it's possible to make any part of site2 *appear* to be a part of site1... but again, that's a problem that boils down to two sites sharing the same role, Anonymous. I'm not saying that creating different Anonymous roles is warranted, BTW... but as far as I can tell, role sharing is the nature of the problem. If you configure priv_method in folder2 such that it is only viewable by folder2_admin, you won't be able to see it if your role is folder1_admin. This suggests that the roles required for privileged operations should be tailored very carefully so as to available only to those intended to have them. Re-using roles is too permissive in most cases. Or have you really found a way to circumvent site-specific roles?
3. Disable/restrict "view folder contents" permissions for all folders
I don't see this permission anywhere... Do you mean "Access contents information" ?
Yes... that's what it's called. I think it was "view folder contents" at one point, but it's obviously not called that any more. :-)
I would add that turning off WebDAV access for anonymous users is a good idea.
Absolutely. Dylan
Having multiple role seems like a huge overkill. When you get down to it, the users are defined in acl_users, a regular object. If you stripped the aquisition wrapper and placed acl_users in the context of the actual container, you would bypass all those problems as the acl_users would only be effective in siblings and their child nodes, which is the expected behavour.
If you configure priv_method in folder2 such that it is only viewable by folder2_admin, you won't be able to see it if your role is folder1_admin. This suggests that the roles required for privileged operations should be tailored very carefully so as to available only to those intended to have them. Re-using roles is too permissive in most cases.
On Sat, 2003-03-29 at 16:40, James Davies wrote:
Having multiple role seems like a huge overkill. When you get down to it, the users are defined in acl_users, a regular object. If you stripped the aquisition wrapper and placed acl_users in the context of the actual container, you would bypass all those problems as the acl_users would only be effective in siblings and their child nodes, which is the expected behavour.
Yes... that will do the trick in many situations, though it has its own significant shortcomings. I use a lot of shared stuff between virtual hosts so it doesn't work for me to choke off privileged upward acquisition. Partitioning roles may only be relevant for certain configurations or it may just be a paranoia layer. I suspect that answering that question will require a great deal more time and effort than I'm currently able to put to the task. Then again, the OP *appears* to have supplied us with an example of where it's necessary. Difficult to say for sure. In any event you should, of course, use the configuration that is best-suited for your particular requirements. Dylan
jamesd@mena.org.au wrote at 2003-3-27 11:39 +1000:
I have a Zope server running with two instances of plone, "Plone1" and "Plone2". plone2 is a demo site with a user "Demo" having the role 'Manager' available to the public. plone1 is a regular plone site.
If I log in to plone2 as the user Demo, then go to the following url: http://my.server/plone2/plone1 The permissions are acquired from the demo site giving full Manager access to my main plone site. This is obviously a serious problem.
Zope tries hard to prevent access to protected objects defined outside of the folder governed by the "acl_users" that authenticated the user. You may have found a hole... Please file a "security related" collector report to <http://collector.zope.org/Zope>. Dieter
participants (6)
-
Dieter Maurer -
Dylan Reinhardt -
george donnelly -
James Davies -
jamesd＠mena.org.au
-
Jamie Heilman