- Zope - Zope lists

ANNOUNCE: Zope 2.6.3 Release and Security Update
by Brian Lloyd 15 Jan '04

15 Jan '04

Zope 2.6.3 Release and Security Update Zope 2.6.3 contains a number of security related fixes for issues resolved during a comprehensive security audit conducted in Q4 2003. You may download Zope 2.6.3 from Zope.org: http://www.zope.org/Products/Zope/2.6.3/ **Users of the VerboseSecurity add-on product for Zope please note:** some of the security-related changes in Zope 2.6.3 are incompatible with the VerboseSecurity product. Please uninstall the VerboseSecurity product before upgrading to 2.6.3 to avoid problems. It is expected that VerboseSecurity will be updated to be compatible with Zope 2.6.3 in the near future. Also note that there are binary code changes in the 2.6.3 release, making it impossible to issue an external "hotfix" to resolve these issues. CVS users should be sure to update their sites **and rebuild the C Python extensions** to ensure that all fixes are deployed. In the fourth quarter of 2003, a comprehensive evaluation of the changes to Python from version 2.1 to 2.3.3 was undertaken. This evaluation was designed to assess each change to the Python environment in terms of its potential impact on the Zope application server and Zope applications, with the goal of making Python 2.3.3 the required Python platform for Zope beginning with Zope 2.7. The evaluation was focused on assessing changes to Python in the following contexts: - Changes that would have compatibility or other effects on existing or new Zope applications - Changes that could potentially affect the Zope security architecture or change the behavior of the restricted execution environment used by Zope to run untrusted code In the course of the evaluation, very few of the Python changes in 2.3.3 directly affected the Zope security architecture or had impacts on the restricted execution model. However, a number of pre-existing potential issues were discovered and resolved in the course of the comprehensive security audit that was performed as a part of the Python upgrade evaluation. Zope 2.6.3 provides fixes for all of these issues. A description of each issue, who is affected and issue status is included below. For more information on what is new in this release, see the CHANGES.txt and HISTORY.txt files for the release: - http://www.zope.org/Products/Zope/2.6.3/CHANGES.txt - http://www.zope.org/Products/Zope/2.6.3/HISTORY.txt For more information on the available Zope releases, guidance for selecting the right distribution and installation instructions, please see: http://www.zope.org/Documentation/Misc/InstallingZope.html ISSUES RESOLVED BY Zope 2.6.3: - For loops, list comprehensions, and other iterations in untrusted code Issue Description Iteration over sequences could in some cases fail to check access to an object obtained from the sequence. Subsequent checks (such as for attributes access) of such an object would still be performed, but it should not have been possible to obtain the object in the first place. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - List and dictionary instance methods in untrusted code Issue Description List and dictionary instance methods such as the get method of dictionary objects were not security aware and could return an object without checking access to that object. Subsequent checks (such as for attributes access) of such an object would still be performed, but it should not have been possible to obtain the object in the first place. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Use of import as in untrusted code Issue Description Use of "import as" in Python scripts could potentially rebind names in ways that could be used to avoid appropriate security checks. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Use of min, max, enumerate, iter, and sum in untrusted code Issue Description A number of newer built-ins were either unavailable in untrusted code or did not perform adequate security checking. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Broken binding validation in untrusted code Issue Description The variables bound to page templates and Python scripts such as "context" and "container" were not checked adequately, allowing a script to potentially access those objects without ensuring the necessary permissions on the part of the executing user. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Unpacking in untrusted code Issue Description Unpacking via function calls, variable assignment, exception variables and other contexts did not perform adequate security checks, potentially allowing access to objects that should have been protected. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Unicode passed to RESPONSE.write() could shutdown process Issue Description Inadequate type checking could allow unicode values passed to RESPONSE.write() to be passed into deeper layers of asyncore, where an exception would eventually be generated at a level that would cause the Zserver main loop to terminate. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - PythonScript class security not initialized properly Issue Description Class security was not properly intialized for PythonScripts, potentially allowing access to variables that should be protected. It turned out that most of the security assertions were in fact activated as a side effect of other code, but this fix is still appropriate to ensure that all security declarations are properly applied. Who Is Affected? Sites that use Python Scripts. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - XML-RPC instance marshaling may disclose protected values Issue Description XML-RPC marshalling of class instances used the instance __dict__ to marshal the object, and could include attributes prefixed with an underscore name. These attributes are considered private in Zope and should generally not be disclosed. Who Is Affected? All Zope sites. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - DTML tag dtml-tree may allow DoS attack Issue Description The dtml-tree tag used an "eval" of user-supplied data; its efforts to prevent abuse were ineffective. Who Is Affected? All Zope sites. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Potential cross-site scripting problem in default ZSearch interface Issue Description Browsers that do not escape html in query strings such as Internet Explorer 5.5 could potentially send a script tag in a query string to the ZSearch interface for cross-site scripting. Who Is Affected? Sites that use the default ZSearch interface. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Proxy rights on DTMLMethods transferred via acquisition Issue Description DTMLMethods with proxy rights could incorrectly transfer those rights via acquisition when traversing to a parent object. Who Is Affected? Sites that allow users who have increased permissions in subfolders to write DTMLMethods. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Improper security assertions on DTMLDocument objects Issue Description Some improper security assertions on DTMLDocument objects could potentially allow access to members that should be protected. Who Is Affected? Sites that use DTMLDocuments for secure content. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - PropertyManager 'lines' and 'tokens' properties stored as list Issue Description Some property types were stored in a mutable data type (list) which could potentially allow untrusted code to effect changes on those properties without going through appropriate security checks in particular scenarios. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Inadequate security assertions on admin "find" functions Issue Description Inadequate security assertions on administrative "find" methods could potentially be abused. Who Is Affected? All Zope sites. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - ZTUtils.SimpleTree state handling Issue Description The ZTUtils SimpleTree decompressed tree state data from the request without checking for final size, which could allow for certain types of DoS attacks. Who Is Affected? Sites that rely on the ZTUtils.SimpleTree. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Configuration file did not override security policy selection Issue Description This is not really a security issue, just a usability issue. It has always been possible to alternate between C and Python implemenations of the Zope security policy using certain environment variables. As of Zope 2.7, use of environment variables is deprecated in favor of the new 2.7 configuration files. The new configuration machinery was not implementing the directive used to override the default security policy. Who Is Affected? Zope 2.7 beta users. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher.

15 25

Re: FieldedTextIndex weighting implemented
by Casey Duncan 15 Jan '04

15 Jan '04

[CC'd the list in case anybody else is interested] On Mon, 12 Jan 2004 17:44:52 -0500 Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca wrote: > Casey, > > I created the Index, and that works fine, using the only ZCLexicon I > have which is the same I use for ZCTextIndexes ... > > Now if I try to view the management page for the Index by clicking on > it in the ZMI, I get : > > Traceback (innermost last): > > Module ZPublisher.Publish, line 89, in publish > Module ZPublisher.BaseRequest, line 299, in traverse > Module Products.ZCatalog.ZCatalogIndexes, line 109, in > __bobo_traverse__ AttributeError: _catalog Hmm, I'm not sure how the index could be causing that. Pretty weird. > After navigating the portal_catalog interface a bit (This is in CMF > BTW), the problem seems to go away ... > > Once I've reached this point, I can go ahead and index content. > > I'd suggest adding to the ZMI interface of the index the name of the > attribute/method being indexed, it's always handy. Good point. I thought I'd done that. I definitely will. > I'll let you know how the actual searching goes ! > > Some thought's I'm having: It'd be nice if I could store default > weights into the index, that it would use transparently, unless > specific weights are provided with the query itself. Also it provides > an easy to use interface to set weights, instead of having to change > code (Possibly often, when one tweaks this stuff). AND, because (In > my case at least) 99% of searches are on ALL fields anyways, it > prevents me from having to supply a list of fields and weights each > and everytime. Yes that makes sense. I'll need to implement weighting when searching all fields which should be straightforward and useful. > The current setup is good for advanced searching and so on, but for > basic"enter text/hit search" queries, it's more work. Yes, that makes sense. > Not a big deal, but an idea for 1.0 I guess ? :) I'll probably shoot for 0.3... > Also, and this is muddy in my mind also, but would having different > weights per object type make some kind of sense ? Since Okapi's > scoring is sensitive to the proportion of terms vs total number of > words, the weighing might need to change based on the type of object, > and whether one attribute's textual content is "wordier" than another. > I don't know if that > makes sense ? It could be done, but it would require changing the data structures since the weights would be applied at query time but would need to be stored at index time. Actually being able to weight objects arbitrary might be pretty interesting. It would allow you to pull tricks like Google and make certain results always rate high for certain queries. I'm not sure if that's what you were thinking but it could be a pretty cool trick. > Oh, and I'm noticing FieldedTextIndex uses Okapi ONLY ? That's fine > for me at least, but might want to document that, for those that might > use the other algorithm ? For simplicity sake I chose to do Okapi only. Doing both would be pretty complex and I didn't think it was worth the effort since I always use Okapi myself. I'm going to call YAGNI on this for now. > Phew, sorry, I'm babbling ... No, the input is always appreciated. -Casey > -----Original Message----- > From: Casey Duncan [mailto:casey@zope.com] > Sent: Monday, January 12, 2004 1:15 AM > To: Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca > Cc: zope(a)zope.org > Subject: FieldedTextIndex weighting implemented > > > I have an initial implementation of the per-field weighting checked > into cvs. I haven't released 0.2 yet, but I expect to sometime in the > next week or so. The new feature is unit-tested and documented in the > README, so feel free to check it out in the mean time. > > You can download it directly from CVS at: > > http://cvs.zope.org/Products/FieldedTextIndex/ > > There is a link to generate a tarball at the bottom, or you can check > in out using anonymous cvs if you want to track changes. > > Let me know what you think. > > -Casey

1 0

2.7.0-b4 problem - unable to rename items
by Nesbitt, Steve 15 Jan '04

15 Jan '04

All: I am getting an AttributeError, ErrorValue: max whenever I try to rename an item using 3.7.0-b4. I do not see any other information in the logs. System is: Zope: 2.7.0-b4 os: linux2 Python: Python 2.3.3, Plone: CMFPlone-2.0-RC3 CMF: 1.4.2. Thanks in adavance for any help. -steve Stephen Nesbitt Senior Configuration Management Engineer The Cobalt Group snesbitt(a)cobaltgroup.com

2 1

Re: [Zope-DB] ERROR(200) Conflict Resolution Unexpected error)
by Dieter Maurer 14 Jan '04

14 Jan '04

I redirected the response to "zope(a)zope.org" where is it better placed. Gerhard Schmidt wrote at 2004-1-14 16:19 +0100: >we are running an zope system with one ZEO and six Zope Frontends > >The system ist running for one Month without a problem under >zope2.7b3 > >Today I had several errors in the zeo.log. > >2004-01-14T16:01:34 ERROR(200) Conflict Resolution Unexpected error >Traceback (most recent call last): > File "/usr/local/www/Zope/lib/python/ZODB/ConflictResolution.py", line 109, in tryT >oResolveConflict > old = state(self, oid, oldSerial, prfactory) > File "/usr/local/www/Zope/lib/python/ZODB/ConflictResolution.py", line 38, in state > p = p or self.loadSerial(oid, serial) > File "/usr/local/www/Zope/lib/python/ZODB/FileStorage.py", line 712, in loadSerial > raise POSKeyError(serial) >POSKeyError: 0000000000000000 This can happen when you recently packed the ZODB. In this case, the original version of the object may no longer be available. Beside the log entry above, this should have no other effect. >Soon all fronends run out of service and this error is logged. Do you see any log entries in the frontends log files? The exception in the server should cause a "ConflictError" in one of its clients. This client should retry its request. All other clients should be unaffected. Or, to say it differently, your frontends should not die due to the above problem. >I have rebuild the Data.fs with fsrecover.py. No Errors reported >but its runnig again. But still some of the above errors are logged >in zeo.log. > >Anybody some Idea what caused this failure. Do you pack your database continuously? Usually (infrequent packing), one would expect that the problem above would occur with a very small probability... -- Dieter

1 0

Problem inserting <dtml-var sequence-item> using ZSQL method in a dtml-in tag
by Gabriela LÃ³pez Ruiz 14 Jan '04

14 Jan '04

Hi all, I'm here again. Now I have a problem trying to insert a group of records in a relational table. I'm using ZSQL and the fact is that in the second column (statement_template_id) I need to insert the actual value of the sequence-item. But I can't use it in the dtml-call tag. When I print it in the HTML table, the value is ok but I need to insert that value in the statement_template_id. How can I get the sequence_item value to insert it in the table? <dtml-in actual_boolean_value> <td><tr> <dtml-var actual_boolean_value><dtml-var sequence-item> </td></tr> <dtml-call "updateStatementValues( checklist_id=_['checklist_id'], statement_template_id=<dtml-var sequence-item>)"> </dtml-in> Thanks a lot for your suggestions. Gabriela. _________________________________________________________________ Charla con tus amigos en línea mediante MSN Messenger: http://messenger.latam.msn.com/

2 1

Sequence.sort error
by Zanotti Michele 14 Jan '04

14 Jan '04

Hi all This dtml instruction: <dtml-in expr="_.sequence.sort(myCatalog(),((_.string.split(ordper)[0],'nocase','asc' ),(_.string.split(ordper)[1],'nocase','asc')))" size=num start=query_start> Gives me (Zope 2.6.3) this error: Traceback (innermost last): Module ZPublisher.Publish, line 150, in publish_module Module ZPublisher.Publish, line 114, in publish Module Zope.App.startup, line 202, in zpublisher_exception_hook Module ZPublisher.Publish, line 98, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 39, in call_object Module OFS.DTMLMethod, line 127, in __call__ Module DocumentTemplate.DT_String, line 474, in __call__ Module DocumentTemplate.DT_In, line 443, in renderwb Module DocumentTemplate.DT_Util, line 201, in eval __traceback_info__: ordper Module <string>, line 2, in f Module DocumentTemplate.sequence.SortEx, line 103, in sort TypeError: unhashable type (Also, an error occurred while attempting to render the standard error message.) In Zope 2.5 this code works (no errors), why? Thanks Michele

2 1

Cookie Crumbler - Help modifying source
by Samir Mishra 14 Jan '04

14 Jan '04

Hi all, I'm using Cookie Crumbler to authenticate users. On login failure, or success for that matter, Cookie Crumbler strips the request of all info. What I'd like it to NOT do is delete cookies I'm setting just before the user is required to login. I believe I'll have to modify the source code to be able to do this. I'm hoping someone could help me modify the source, and if there's a better way to go about achieving this, suggestions will be appreciated. Thanks in advance. Samir.

3 2

ZODB A storage error occured during transaction abort.
by Dennis Allison 14 Jan '04

14 Jan '04

Dieter, Your lucid description of the source of the "AttributeError: Surrogate instance has no attribute '_p_oid'" error in the mailing list archives explains what's happening, but I am at a loss to identify the method that registers the surrogate and does not have an _p_oid instance. My problem is trying to identify the source of the failure. There are a couple of external procedures used in the QLOG method which caused the conflict error, but nothing other than vanilla DTML nearby in the log. Do you have any suggestions for localizing the problem? This is all running on Zope 2.6.2b3, Python 2.3.1, RH7.3. ------------------------------------------------------------------- >From the error log: 2004-01-13T17:15:21 ERROR(200) ZODB A storage error occured during transaction abort. This shouldn't happen. Traceback (innermost last): File /home/zopesys/lib/python/ZODB/Transaction.py, line 262, in commit File /home/zopesys/lib/python/ZODB/Transaction.py, line 393, in _commit_error AttributeError: Surrogate instance has no attribute '_p_oid' ------ 2004-01-13T17:15:21 INFO(0) ZODB conflict error at /lms/QLOG (2 conflicts since startup at 2004-01-13T12:24:00) ------ 2004-01-13T17:29:07 INFO(0) Z2 Caught signal SIGTERM ------ 2004-01-13T17:29:07 INFO(0) Z2 Closing all open ZODB databases ------

2 1

Zope install/startup problems on Debian Sarge
by Goran Christiansson 14 Jan '04

14 Jan '04

Dear All, I have installed Zope on Debian Sarge (testing), but I cannot log into the ZMI. I got the package using "apt-get install zope", created an instance using: > zopectl init default > zopectl access default (I made a password using the zpasswd.py script) > zopectl restart The instance seems to start all right. On port 9673 I get the Zope introduction text. However, when I try to access /manage, I get a Error 500 page in my browser. The detailed log file contains: U 000000000 2004-01-14T21:51:01 System startup B 150241180 2004-01-14T21:51:06 GET /manage I 150241180 2004-01-14T21:51:06 0 A 150241180 2004-01-14T21:51:06 401 705 U 000000000 2004-01-14T21:51:07 System startup B 150240820 2004-01-14T21:51:15 GET /manage I 150240820 2004-01-14T21:51:15 0 A 150240820 2004-01-14T21:51:15 401 705 U 000000000 2004-01-14T21:51:16 System startup B 150240764 2004-01-14T21:52:10 GET /manage I 150240764 2004-01-14T21:52:10 0 Where should I start looking? Thanks, Göran

2 1

LDAP - Zope - ACLUsers &- Manage Local Roles
by Julian Clark 14 Jan '04

14 Jan '04

Hi List. I've recently recreated a zope installation that someone else built, in the process updating to zope 2.6 from 2.3.3 I'm not having much joy with LDAP + local roles upon the manage local role interface. I've discovered in the dtml source for listLocalRoles there is a try/except for overflow, which is being caught and therefore not bringing the list of users up. Does this mean that my ldap server is returning too many results? It works properly on zope 2-3-3 without a try/except statement. Is there something else I can do to stop the overflow error? I feel that with this out of the way, everything else will work properly (I hope) When I manually enter a user name and assign a local role, then attempt to test it, the LDAP log shows a successful authentication, however, I'm still getting unauthorized errors. :( this is an extract from the LDAP log.. (9) Mon 11:51: Checking julcla (9) Mon 11:51: julcla not found in user cache (9) Mon 11:51: Opened connection to ldap server (9) Mon 11:51: Closed connection to ldap server (9) Mon 11:51: julcla connect returned cn=Julian Clarke (julcla),ou=people,dc=b-online,dc=com,dc=au,o=internet (5) Mon 11:51: julcla user authenticated (9) Mon 11:51: Checking julcla (9) Mon 11:51: julcla found in user cache (7) Mon 11:51: julcla authenticated from cache (9) Mon 12:02: Checking julcla (9) Mon 12:02: julcla found in user cache (7) Mon 12:02: julcla authenticated from cache Which gives me the impression that I should be able to login from here. However, I am continuously prompted for username & password, which always fails, when I cancel, I get these errors... Time 2004/01/12 12:01:58.342 GMT+0800 User Name (User Id) Anonymous User (None) Request URL http://testserver/knowledge_backup/index_html Exception Type Unauthorized Exception Value <strong>You are not authorized to access this resource.</strong> Traceback (innermost last): * Module ZPublisher.Publish, line 89, in publish * Module ZPublisher.BaseRequest, line 436, in traverse * Module ZPublisher.HTTPResponse, line 667, in unauthorized Unauthorized: <strong>You are not authorized to access this resource.</strong> Time 2004/01/12 12:02:03.049 GMT+0800 User Name (User Id) julcla (julcla) Request URL http://testserver/knowledge_backup/index_html Exception Type Unauthorized Exception Value You are not allowed to access -1 in this context Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module OFS.DTMLMethod, line 126, in __call__ * Module DocumentTemplate.DT_String, line 474, in __call__ * Module DocumentTemplate.DT_With, line 76, in render * Module OFS.DTMLMethod, line 119, in __call__ * Module DocumentTemplate.DT_String, line 474, in __call__ * Module DocumentTemplate.DT_With, line 76, in render * Module OFS.DTMLMethod, line 119, in __call__ * Module DocumentTemplate.DT_String, line 474, in __call__ * Module OFS.DTMLMethod, line 119, in __call__ * Module DocumentTemplate.DT_String, line 474, in __call__ * Module DocumentTemplate.DT_Util, line 201, in eval __traceback_info__: PARENTS * Module <string>, line 2, in f * Module AccessControl.DTML, line 32, in guarded_getitem * Module AccessControl.ZopeGuards, line 94, in guarded_getitem Unauthorized: You are not allowed to access -1 in this context Any Suggestions would be greatly appreciated. Thanks in advance. Julian Clark

2 3