[Zope-dev] RE: Resolved security-related collector issues for thepublic?
Hi Brian, Brian Lloyd wrote: As the person who unfailingly gets flamed no matter which way the decisions leans :), I think we are probably at a point where we should have an official, documented and community-agreed-to policy on how these kinds of things will be handled. My intent was not flaming anyone... Sorry for that. I just tried to take the voice of the average Zope-Admin (installs Zope from a recent stable release, waits for the security-maintainers of distros to get security patches etc.). At a minimum, having a clear and documented policy would provide the benefit of 'no surprises' - if you disagree with the policy, or some aspect of it, you would at least be able to plan around it. Very good idea...:) If all Zope-Admins can read before an installation: Security exploits will be exposed to the public as soon as they're resolved in the CVS everyone will should run Zope out of CVS. My point was: Give people a chance to react on exposed security flaws. The statement above will do that because people should be prepared...:) Cheers, Maik ___ 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] Resolved security-related collector issues for the public?
[...] there were several security-related fixes in the collector (and the collector-mailing-list) in the last days. Normaly security-related stuff is not visible for the public... and this seems to be good to avoid exploits etc. At least for the resolved issues the fixed are public available from the CVS (maybe even together with log messages). Sufficiently skilled people thus can reconstruct the security issues from the changes; I feel there is no point for hiding them any longer. On the other hand admins may be less pressed to upgrade if they look at the current available list of fixes and find none which hurts them in their setup ... for example I do not have untrusted users able to write 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 to blow my site with one of the not yet published issues. my 2 cents, Clemens btw: it does not look like either zope.org nor zope.com has been upgraded yet? The find-support still looks quite public ... ___ 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?
Brian Lloyd wrote: As the person who unfailingly gets flamed no matter which way the decisions leans :), I think we are probably at a point where we should have an official, documented and community-agreed-to policy on how these kinds of things will be handled. My intent was not flaming anyone... Sorry for that. I just tried to take the voice of the average Zope-Admin (installs Zope from a recent stable release, waits for the security-maintainers of distros to get security patches etc.). Sorry, I should have been more clear. I didn't mean to imply that your or Jamie's notes were flames (they're definitely not), just that I'd been singed in the past ;) At a minimum, having a clear and documented policy would provide the benefit of 'no surprises' - if you disagree with the policy, or some aspect of it, you would at least be able to plan around it. Very good idea...:) If all Zope-Admins can read before an installation: Security exploits will be exposed to the public as soon as they're resolved in the CVS everyone will should run Zope out of CVS. ...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. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ 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: RFC: backward compatibility of ps bindingsRESOLUTION
I did check with a fresh 2.6 xx
A DCWorkflow script that was not not called with the version from a few
hours ago is now called but produces the following traceback
This happens when the container binding is set to container and also
when it is cleared.
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 Products.CMFCore.FSPythonScript, line 92, in __call__
Module Shared.DC.Scripts.Bindings, line 298, in __call__
Module Shared.DC.Scripts.Bindings, line 329, in _bindAndExec
Module Products.CMFCore.FSPythonScript, line 126, in _exec
- __traceback_info__: ({'traverse_subpath': [], 'container':
PloneSite instance at 95efa58, 'context': PloneFolder instance
at 9615280, 'script': FSPythonScript at
/zehnder/zehnder/createObject used for
/zehnder/zehnder/tasklist/Task.2004-01-21.1914/Attachments},
(None, 'File', None), {}, (None, None, None))
Module None, line 12, in createObject
Module Products.CMFCore.PortalFolder, line 362, in invokeFactory
Module Products.CMFCore.TypesTool, line 824, in constructContent
Module Products.CMFCore.TypesTool, line 516, in constructInstance
Module Products.CMFCore.TypesTool, line 420, in _finishConstruction
Module Products.CMFCore.CMFCatalogAware, line 101, in
notifyWorkflowCreated
Module Products.CMFPlone.WorkflowTool, line 26, in notifyCreated
Module Products.CMFCore.WorkflowTool, line 362, in notifyCreated
Module Products.DCWorkflow.DCWorkflow, line 367, in notifyCreated
Module Products.DCWorkflow.DCWorkflow, line 440, in _changeStateOf
Module Products.DCWorkflow.DCWorkflow, line 543, in _executeTransition
Module Shared.DC.Scripts.Bindings, line 298, in __call__
Module Shared.DC.Scripts.Bindings, line 329, in _bindAndExec
Module Products.PythonScripts.PythonScript, line 311, in _exec
Module None, line 1, in setTaskOwner
- PythonScript at
/zehnder/zehnder/portal_workflow/ZWorkflow/scripts/setTaskOwner
- Line 1
AttributeError: StateChangeInfo instance has no attribute
'getPhysicalRoot'
Robert
It would be helpful if you could go through that in the debugger
and see if you can get any more info - I don't see anything in
this that obviously points to any of the recent security changes.
That's not to say that one of those changes couldn't still be the
cause, but this traceback doesn't point to anything we can look
at :(
Alternatively, if you can make a copy of the failing script and
boil it down to the minimum possible code that demostrates something
that should be working but isn't (and that excludes app-specific or
Plone objects if possible so that we can turn it into a unit test)
I can try to look at it here.
thx,
Brian Lloyd[EMAIL PROTECTED]
V.P. Engineering 540.361.1716
Zope Corporation http://www.zope.com
___
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] Resolved security-related collector issues for the public?
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. -- Jamie Heilman http://audible.transient.net/~jamie/ ...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity... -Rimmer ___ 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?
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?
On Fri, Jan 23, 2004 at 09:45:43AM +1300, Richard Waid wrote: 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. OK, but what if there is no patch, hotfix, or workaround ready after 2-7 days? Some of these bugs have taken much longer. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's PSUEDO LIGHTNING FRED! (random hero from isometric.spaceninja.com) ___ 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] Resolved security-related collector issues for the public?
Jamie Heilman writes: 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. Thanks for the clarification. I just tried to argue from a rather ignorant point of view ... I could argue some more about why these issues look not so dangerous to me, but even if I try hard, I cannot be so ignorant ;) Actually I only tried to point out that if someone would tell me there is another yet not published issue that would allow to read the password of my users TTW or the like, this would make me upgrade even in very ignorant mode. However when obscuring these issue this will ignorant (or just busy) admins not help a lot; they will upgrade after these issues are published, not after the fixes are released ... meanwhile black hats checking with the CVS may have their exploits applied already. About the current discussion of a security (non-)disclosure policy: I would be happy with a policy which makes security issues public if a fix from the public CVS is available. (Well, I am running Zope form the CVS, so my position is maybe a little biased ;-) Cheers, Clemens ___ 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] Re: RFC: backward compatibility of ps bindingsRESOLUTION
Brian Lloyd wrote:
I did check with a fresh 2.6 xx
A DCWorkflow script that was not not called with the version from a few
hours ago is now called but produces the following traceback
This happens when the container binding is set to container and also
when it is cleared.
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 Products.CMFCore.FSPythonScript, line 92, in __call__
Module Shared.DC.Scripts.Bindings, line 298, in __call__
Module Shared.DC.Scripts.Bindings, line 329, in _bindAndExec
Module Products.CMFCore.FSPythonScript, line 126, in _exec
- __traceback_info__: ({'traverse_subpath': [], 'container':
PloneSite instance at 95efa58, 'context': PloneFolder instance
at 9615280, 'script': FSPythonScript at
/zehnder/zehnder/createObject used for
/zehnder/zehnder/tasklist/Task.2004-01-21.1914/Attachments},
(None, 'File', None), {}, (None, None, None))
Module None, line 12, in createObject
Module Products.CMFCore.PortalFolder, line 362, in invokeFactory
Module Products.CMFCore.TypesTool, line 824, in constructContent
Module Products.CMFCore.TypesTool, line 516, in constructInstance
Module Products.CMFCore.TypesTool, line 420, in _finishConstruction
Module Products.CMFCore.CMFCatalogAware, line 101, in
notifyWorkflowCreated
Module Products.CMFPlone.WorkflowTool, line 26, in notifyCreated
Module Products.CMFCore.WorkflowTool, line 362, in notifyCreated
Module Products.DCWorkflow.DCWorkflow, line 367, in notifyCreated
Module Products.DCWorkflow.DCWorkflow, line 440, in _changeStateOf
Module Products.DCWorkflow.DCWorkflow, line 543, in _executeTransition
Module Shared.DC.Scripts.Bindings, line 298, in __call__
Module Shared.DC.Scripts.Bindings, line 329, in _bindAndExec
Module Products.PythonScripts.PythonScript, line 311, in _exec
Module None, line 1, in setTaskOwner
- PythonScript at
/zehnder/zehnder/portal_workflow/ZWorkflow/scripts/setTaskOwner
- Line 1
AttributeError: StateChangeInfo instance has no attribute
'getPhysicalRoot'
Robert
It would be helpful if you could go through that in the debugger
and see if you can get any more info - I don't see anything in
this that obviously points to any of the recent security changes.
That's not to say that one of those changes couldn't still be the
cause, but this traceback doesn't point to anything we can look
at :(
Alternatively, if you can make a copy of the failing script and
boil it down to the minimum possible code that demostrates something
that should be working but isn't (and that excludes app-specific or
Plone objects if possible so that we can turn it into a unit test)
I can try to look at it here.
thx,
Brian Lloyd[EMAIL PROTECTED]
V.P. Engineering 540.361.1716
Zope Corporation http://www.zope.com
Brian,
I tried hard to recreate the problem in isolation but failed. So it must
be something whith what we are doing.
Strange that our code works fine with 2.62.
thanks again
Robert
___
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 )
