Re: [Zope-dev] RE: Resolved security-related collector issues forthepublic?
Brian Lloyd wrote: ...or will decide that doing so is unreasonable and use something else instead :( Note that I'm not necessarily criticizing that particular policy, just pointing out that _any_ policy will have some upside and some downside. The challenge will be coming to agreement on a policy with the right balance that everyone can live with. How about something along the lines of: - Development team only disclosure for the first x days (2 to 7 days is the maximum here I would think), in order to develop a workaround/patch. - Full disclosure after that, along with a published patch, hotfix or workaround. Other recommendations: - Increase the number of people who have access to the security section of the collector, to increase the chance that it will be discussed. - Form a closed security list for discussing such things amongst selected developers, away from the general public gaze (does such a thing already exist?) At some stage the sysadmin has to take responsibility for the packages they are using. I tend to believe, as almost certainly most of the security community does, that not all crackers are just script-kiddies waiting for an exploit. Lets face facts -- if someone is reporting an exploitable hole, anyone else (white/black/grey hat) could have also found it. I for one would love to know things like: Jamie Heilman wrote: Clemens Robbenhaar wrote: malicious Python Scripts on my site (I guess , and I do not use DTML or some Tree-stuff -- thus I did not upgrade yet, and You may feel free Actually... unless you've altered the ZMI and HelpSys, you do use dtml-tree ...and HelpSys is publically traversable by default. Anyone else spot the irony in the situation that _all_ the available security holes are available to a user who cracks the Zope collector site? --Richard ___ 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 )
Re: [Zope-dev] RE: Resolved security-related collector issues forthepublic?
Paul Winkler wrote: On Fri, Jan 23, 2004 at 09:45:43AM +1300, Richard Waid wrote: How about something along the lines of: - Development team only disclosure for the first x days (2 to 7 days is the maximum here I would think), in order to develop a workaround/patch. - Full disclosure after that, along with a published patch, hotfix or workaround. OK, but what if there is no patch, hotfix, or workaround ready after 2-7 days? Some of these bugs have taken much longer. I think we need to be looking at _why_ the bugs have taken much longer. Is it strictly lack of resources? Security fixes, generally, shouldn't come in batches of 10 (or whatever) because, even if they're related, it makes testing the critical-security-patch-that-needs-to-be-applied-right-now extremely difficult for almost everyone. --Richard ___ 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 )
Re: [Zope-dev] New-style ExtensionClasses (Zope 2.8) -- MRO issue
Jim Fulton wrote: snip 3. Use a hybrid schema. I'll call this the encapsulated base scheme. snip Is it possible for the hybrid schema to generate a 'deprecation' warning for each instance of a class that doesn't match the requirements of the C3 resolution order when Zope is first started, and thus increase the chances that product authors will modify their products (or be coerced to do so :)), without actually breaking them? --Richard ___ 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 )
Re: [Zope-dev] Re: 2.7.0-b2 - Critical ZPT TAL bug when using content-type text/xml
Evan Simpson wrote: Until cAccessControl.c is fixed, you can work around the problem with a simple patch to Products/PageTemplates/Expressions.py, in restrictedTraverse(): if isinstance(name, TupleType): object = object(*name) continue + + name = str(name) if not name or name[0] == '_': # Skip directly to item access Thanks Evan (definitely a better idea that turning off guarded_getattr anyway :)). Any hunches why it doesn't happen in 2.6.x? (maybe the xml didn't get converted to unicode?) I'd imagine that it's probably quite a pervasive bug -- comparing two strings is obviously quite a common situation ... just turned up by this particular situation. Just a quick grep turns up 50 instances of PyString_Check in the 2.7.0-b2 source, and 4 instances of PyUnicode_Check. cDocumentTemplate.c and UnicodeSplitter.c (no suprises there) seem to do the right thing. Pretty much every other c file needs to be checked. In particular cPersistence.c, cPickleCache.c, Acquisition.c, ComputedAttribute.c, ExtensionClass.c and cAccessControl.c all use PyString_Check, and they'd obviously be bad places for things to go wrong :) Best regards, Richard Waid Network/Software Engineer http://iopen.net ___ 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] 2.7.0-b2 - Critical ZPT TAL bug when using content-type text/xml
Yesterday I discovered a bug in ZPT for which I'm having trouble tracking down the source. This bug does not appear to occur in 2.6, but does appear to occur in both 2.7.0-b2 and 2.7.0-b1. Basically, if you're using a ZPT with a content-type text/xml, using a TAL path expression to access an attribute or method causes a security violation (Unauthorized). It does not happen if the ZPT is using content-type text/html. This is a critical bug for us, it will affect dozens if not hundreds of XML producing ZPT's if we were to upgrade to 2.7 from 2.6. I notice that someone previously reported something like this on the Zope list but I couldn't find a resolution (the message was a couple of months back), and there is a bug in the collector: http://collector.zope.org/Zope/1034/ To which I have added a comment, a test case and a traceback. The bug was talking about METAL macros, but it is almost certainly related. Two things are known to workaround this bug: 1) ZOPE_SECURITY_POLICY=PYTHON would probably work, since I forced an import error in AccessControl/ZopeGuards.py to force the use of the python version of guarded_getattr, and that fixed the problem. Which might suggest the problem is in cAccessControl ... though I dropped in the 2.6 version of that, and it didn't seem to fix the problem (maybe something in cAccessControl is only trigged under this scenerio), 2) Using getattr rather than guarded_getattr in PageTemplates/Expressions.py, line 348. Not the best solution :) The test case, for those too lazy to look in the collector (:)): --- 1. Create a page template 2. Use the text: test xmlns:tal=http://xml.zope.org/namespaces/tal; tal:replace=here/id/ 3. Set to content-type text/html -- it should work when you test it. 4. Set to content-type text/xml -- you will get a security violation when you test it (Unauthorized: You are not allowed to access 'id' in this context). - Any help tracking down this problem would be very greatly appreciated. Many thanks, Richard Waid Network/Software Engineer http://iopen.net ___ 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 )
