[Zope] BIG security hole in www.zope.org

David Kankiewicz i173327@thegrid.net
Thu, 16 Sep 1999 16:21:20 -0700


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 )