[Zope-dev] How (in)secure is Zope?

[Chris McDonough]

Hi Jamie,

I'm wondering if you might consider applying for checkin privileges. 
The host header issue that you've uploaded several patches for is a
bonafide problem for some users, but I think that most people with
checkin privs feel that it isn't sufficiently dangerous to the majority
of users to take the time out to review all of your patches and vouch
for them via a checkin (this might take a day or so to do). OTOH, if you
could just check them in yourself, you would no longer feel
disenfranchised.

The process for obtaining checkin privileges is documented here:  

http://dev.zope.org/CVS/ContributorIntroduction

HTH,

- C


On Thu, 2003-03-13 at 06:42, Jamie Heilman wrote:
> Max M wrote:
> > A statement like that without an argument is worthless in a discussion. 
> > You need to elaborate as we cannot read your mind and see what lies 
> > behind the statement.
> 
> My statement wasn't really aimed at you, sorry, I'm not playing fair.
> My statement was aimed at people who don't have to read my mind
> because they've been informed, and I'm making it in a public forum to
> be a pain the ass.
> 
> I've already mentioned I have outstanding security related bugs in the
> collector, and as Toby noted I've been vocal on the value of process
> seperation and resource limits.  This isn't a coincidence.
> 
> Without properly configured resource limits, it is trivial to use an
> exposed Zope instance to exhaust host resources.  This isn't entirely
> Zope's problem, this is usually an issue of misconfiguration.  For
> example, until Zope 2.6, ZServer imposed no length limits on HTTP
> request headers.  (These headers are read directly into memory, thus
> it was fairly easy to exhaust the memory of a host without resource
> limits.) When I found that out I reported it as a bug, and it was
> promptly addressed. (kudos)  Now it could easily be argued, and I
> wouldn't be inclined to really disagree, that header length limits
> should be configured by the fronting server.  What I didn't appreciate
> at the time is just how important a front-end proxy server is for
> Zope.  If you expose Zope to a hostile network, it is mandatory.  So
> now I don't consider this kind of thing a bug in Zope, unless Zope
> happens to make it possible to drastically amplify the effects of such
> an attack, (at which point crashing zope by running it into a resource
> limit becomes trivial) and a front-end proxy is unable or unlikely to
> thwart the attack.
> 
> Zope's bug collector hides security related bugs until they are deemed
> worth of display by the controllers.  Personally I think full
> disclosure is preferable to secrecy, but I'm willing to play by the
> rules laid down as long as I think the system is working for the
> general benefit of the community.  You may have noticed I haven't been
> terribly secretive about recent cross site scripting or cache
> poisoning issues, and that can be attributed to, in part, my growing
> disastifaction with the system.
> 
> -- 
> Jamie Heilman                   http://audible.transient.net/~jamie/
> "Paranoia is a disease unto itself, and may I add, the person standing
>  next to you may not be who they appear to be, so take precaution."
> 						-Sathington Willoughby
> 
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev@zope.org
> 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 )