BIG security hole in www.zope.org
I found this somewhat by accident. I set up a membership and after awhile, wanted to change my index_html. Unfortunately, I didn't get a copy, so it is inheriting the one from above. So, I tried this: http://www.zope.org/Members/adustman/index_html/manage Not only does this work, it lets me make the change. Which is why it presently says, "Hey, man, if you can read this, something is seriously hosed." On the members list, and every member page with the default index_html. Probably the security is set wrong up above (I hope). -- andy dustman | programmer/analyst | comstar.net, inc. telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d
I can see it... I think he's right. Perhaps this is a general Zope problem. He got the index_html through aquisition, and it editted it in place. Perhaps it should work like NewtonScript -- you could get to object attributes in a similar way, but if you changed them, it stored the changed attribute in the local object, rather than in the inheritted object. Like this: ObjectA has attribute A, and ObjectB inherits from ObjectA. You can evaluate an expression like "ObjectB.A" and it would fetch the value from ObjectA. But if you chaged the value, like "ObjectB.A = foo", that created an attribute A in ObjectB. Copy on write, so to speak. On Thu, Sep 16, 1999 at 05:47:53PM -0400, Andy Dustman wrote:
I found this somewhat by accident. I set up a membership and after awhile, wanted to change my index_html. Unfortunately, I didn't get a copy, so it is inheriting the one from above. So, I tried this:
http://www.zope.org/Members/adustman/index_html/manage
Not only does this work, it lets me make the change. Which is why it presently says, "Hey, man, if you can read this, something is seriously hosed." On the members list, and every member page with the default index_html. Probably the security is set wrong up above (I hope).
On Thu, 16 Sep 1999 davidbro@namshub.org wrote:
I can see it... I think he's right.
Perhaps this is a general Zope problem. He got the index_html through aquisition, and it editted it in place.
Perhaps it should work like NewtonScript -- you could get to object attributes in a similar way, but if you changed them, it stored the changed attribute in the local object, rather than in the inheritted object.
Like this: ObjectA has attribute A, and ObjectB inherits from ObjectA. You can evaluate an expression like "ObjectB.A" and it would fetch the value from ObjectA. But if you chaged the value, like "ObjectB.A = foo", that created an attribute A in ObjectB. Copy on write, so to speak.
Yeah, I was hoping it worked that way. Hopefully this is just a problem with the Zope web site and not Zope itself. -- andy dustman | programmer/analyst | comstar.net, inc. telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d
Andy Dustman wrote:
On Thu, 16 Sep 1999 davidbro@namshub.org wrote:
I can see it... I think he's right.
Perhaps this is a general Zope problem. He got the index_html through aquisition, and it editted it in place.
More of a "Management Interface" problem...
Perhaps it should work like NewtonScript -- you could get to object attributes in a similar way, but if you changed them, it stored the changed attribute in the local object, rather than in the inheritted object.
Like this: ObjectA has attribute A, and ObjectB inherits from ObjectA. You can evaluate an expression like "ObjectB.A" and it would fetch the value from ObjectA. But if you chaged the value, like "ObjectB.A = foo", that created an attribute A in ObjectB. Copy on write, so to speak.
Yeah, I was hoping it worked that way. Hopefully this is just a problem with the Zope web site and not Zope itself.
I asked about the security of the site the other day (privately), response was: :Security is a difficult thing to do right. <snip> looks like a security HowTo/Manual should address this interface bug and many other security design issues.
From my own understanding (I'm no guru yet), it would be far safer to restrict anyone risky from accessing Management Interfaces and re-build your own interfaces that behave the way you write them. (Like the above, verify an object where you our, if its in PARENTS create a local object, and then write to the local one...). Sense I planned on doing this already, this bug doesn't mean much to me (except re-inforcing the idea and pointing out acquisition, thanks ;). The use of proxy security roles on the interface methods is almost a must for my own plans.
I haven't seen a true "security" problem yet, but it looks easy to give the wrong access away and not know what someone can do with it. This "design bug" shows acquisition has to be taken into account when creating Management Interfaces, for sure. David, tone
-- andy dustman | programmer/analyst | comstar.net, inc. telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d
_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope
(To receive general Zope announcements, see: http://www.zope.org/mailman/listinfo/zope-announce
For developer-specific issues, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )
On Thu, 16 Sep 1999, Andy Dustman wrote:
I found this somewhat by accident. I set up a membership and after awhile, wanted to change my index_html. Unfortunately, I didn't get a copy, so it is inheriting the one from above. So, I tried this:
http://www.zope.org/Members/adustman/index_html/manage
Not only does this work, it lets me make the change. Which is why it presently says, "Hey, man, if you can read this, something is seriously hosed." On the members list, and every member page with the default index_html. Probably the security is set wrong up above (I hope).
It's way worse than I thought: You can do the same thing with at least standard_html_footer! Hope all you Digital Creations guys haven't gone home yet... -- andy dustman | programmer/analyst | comstar.net, inc. telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d
I took the comment off the publicly viewable site... not to hide the security hole, but to keep from giving the zope.org site a bad name... let's report holes to Digital Creations, not exploit them and make the site look bad... I'm sure you meant well... Tad Murphy "cybertad" http://www.zope.org/Members/cybertad/ ----- Original Message ----- From: Andy Dustman <adustman@comstar.net> To: <zope@zope.org> Sent: Thursday, September 16, 1999 4:47 PM Subject: [Zope] BIG security hole in www.zope.org | I found this somewhat by accident. I set up a membership and after awhile, | wanted to change my index_html. Unfortunately, I didn't get a copy, so it | is inheriting the one from above. So, I tried this: | | http://www.zope.org/Members/adustman/index_html/manage | | Not only does this work, it lets me make the change. Which is why it | presently says, "Hey, man, if you can read this, something is seriously | hosed." On the members list, and every member page with the default | index_html. Probably the security is set wrong up above (I hope). | | -- | andy dustman | programmer/analyst | comstar.net, inc. | telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d | | | _______________________________________________ | Zope maillist - Zope@zope.org | http://www.zope.org/mailman/listinfo/zope | | (To receive general Zope announcements, see: | http://www.zope.org/mailman/listinfo/zope-announce | | For developer-specific issues, zope-dev@zope.org - | http://www.zope.org/mailman/listinfo/zope-dev ) |
On Thu, 16 Sep 1999, Tad Murphy wrote:
I took the comment off the publicly viewable site... not to hide the security hole, but to keep from giving the zope.org site a bad name... let's report holes to Digital Creations, not exploit them and make the site look bad... I'm sure you meant well...
Fine by me, I needed something visible to make sure it worked. I really didn't expect it to work at all. -- andy dustman | programmer/analyst | comstar.net, inc. telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d
I hear ya man... and that email was written in haste... nothing personal at all... but it's a HUGE hole and it made me nervous... I'm glad you found it... next step, let's kill it... people could really screw with the site between now and the time it takes DC to fix the problem... next question... is it fixable at all??? Tad Murphy "cybertad" http://www.zope.org/Members/cybertad/ ----- Original Message ----- From: Andy Dustman <adustman@comstar.net> To: Tad Murphy <murphyt@cybertad.com> Cc: <zope@zope.org> Sent: Thursday, September 16, 1999 5:22 PM Subject: Re: [Zope] BIG security hole in www.zope.org | Fine by me, I needed something visible to make sure it worked. I really | didn't expect it to work at all.
participants (4)
-
Andy Dustman -
David Kankiewicz -
davidbro＠namshub.org -
Tad Murphy