[Zope-dev] Zope - SecurityFocus Newsletter #232 (fwd)
Hi, Can anyone shed light on all of these? I know about some of them, but this is quite a disturbingly long list... cheers, Chris -- Forwarded Message -- Date: Tuesday, January 20, 2004 2:45 PM -0700 From: Kelly Martin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: SecurityFocus Newsletter #232 8. Zope Multiple Vulnerabilities BugTraq ID: 9400 Remote: Yes Date Published: Jan 12 2004 Relevant URL: http://www.securityfocus.com/bid/9400 Summary: Zope is an open source web application server, maintained by the Zope Project. Zope is available for Linux, Unix, and Microsoft Windows based systems. Multiple vulnerabilities have been reported to exist in the software that may allow an attacker to carry out attacks resulting from improper input validation, access validation, information disclosure, and various improper security checks on a vulnerable system. Successful exploitation of these issues may lead to cross-site scripting attacks, denial of service conditions, and other attacks. The following specific issues have been identified: The ZSearch interface has been reported to be prone to a cross-site scripting vulnerability. Successful exploitation of this issue may allow a remote attacker to carry out cross-site scripting attacks by enticing a victim user to follow a malicious link to a site hosting the software that contains embedded HTML and script code. The embedded code may be rendered in the web browser of the victim user in the security context of the site hosting the vulnerable software. A denial of service vulnerability has been identified in 'ZTUtils.SimpleTree' that may allow an attacker to cause a denial of service condition the software. This condition results from improper state handling. An access validation issue has been reported to exist in the admin find functions. This issue may lead to an attacker gaining access to sensitive information without proper authentication. An unspecified access validation issue has been identified in the PropertyManager 'lines' and 'tokens' properties. It has been reported that some property types are stored in a mutable data type (list) and may allow untrusted code to effect changes on the properties without proper security validation. An unspecified access validation issue may exist in the DTMLDocument objects. This issue could allow an attacker to gain access to sensitive information. Another access validation issue has been identified in DTMLMethods. It has been reported that DTMLMethods proxy rights may be incorrectly inherited when traversing to a parent object. A denial of service vulnerability has been identified in DTML tag 'dtml-tree' that may allow an attacker to cause a denial of service condition the software. An information disclosure vulnerability is reported to exist in the software. This issue may allow an attacker to disclose certain attributes via XML-RPC marshalling of class instances. An access validation issue has been reported to exist in the software that may allow unauthorized access to certain variables. This issue occurs due to improper initialization of PythonScript class security. A denial of service vulnerability exists in RESPONSE.write() that may allow an attacker to pass malicious unicode values resulting in Zserver main loop to terminate resulting in a crash or hang. An access validation issue may exist in the software due to Unpacking via function calls, variable assignment, exception variables without sufficient security check. This issue may allow an attacker to gain access to sensitive data. Another access validation issue may allow an attacker to execute a malicious script on a vulnerable system in order to gain unauthorized access to certain objects. This issue results from improper verification of variables bound to page templates and Python scripts such as 'context' and 'container'. An unspecified error has been reported to exist due to the use of min, max, enumerate, iter, and sum in untrusted code. An issue has been identified in the use of 'import as' in Python scripts that may allow an attacker to bypass security checks. Another access validation issue has been identified in the list and dictionary instance methods that may allow an attacker to gain unauthorized access to certain objects. A similar issue has also been identified in for loops, list comprehensions, and other iterations of untrusted code. Further analysis of these issues is currently underway. This BID will be separated into individual BIDs upon completion of analysis. These issues have been reported to exist in Zope versions 2.6.2 and prior and development releases 2.7.0 beta3. Other versions could be affected as well. -- End Forwarded Message -- Richard Hopkins, Information Services, Computer Centre, University of Bristol, Bristol, BS8 1UD, UK Tel +44 117 928 7859 Fax +44 117 929 1576 ___ Zope-Dev maillist - [EMAIL PROTECTED]
Re: [Zope-dev] Zope - SecurityFocus Newsletter #232 (fwd)
Can anyone shed light on all of these? I know about some of them, but this is quite a disturbingly long list... These fixes were mentioned in the last few announcements Brian made, as well as an explanation how several of the issues came to be found. The particular security focus message you've quoted is a summary of Brian's announcement. ... Further analysis of these issues is currently underway. This BID will be separated into individual BIDs upon completion of analysis. Interesting. -- 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 )
[Zope-dev] Re: DCWorkflow still not Working using 2.6.4c1
robert rottermann wrote: Note from the subject: 2.6.4rc1 did *not* contain changes which were expected to fix your issue; in fact, I can't think of any reasonable change (to the Zope core, at least) which would both restore the behavior you want and close the hole. Hi there, the new security regime that changed the rules to acces scripts still prevent my workflow to work. Tres suggestion to give the scripts a proxy role of 'Manager' or clearing the parent parameter in the scripts binding did not help. I have the impressen, that DCWorkflow does not take the proxy role into account . the the script is not called at all, since the security machinery never validates the non Manager user. thanks for any help on how to make that work again. Can you visit your script via DAV/FTP, or at its 'manage_FTPget' URL, and include the output? Also, please repost the traceback you get with that version of the script. Tres. -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers 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 )
[Zope-dev] Zope Start Script Woes
Hi,
These are probably more shell scripting issues, but I'm hoping that
some scripter with an agile mind will show me the error of my ways,
so here goes.
I have borrowed a script from the zope site and modified it for my
purposes, and it 'sort of' works. The issues are:
Can't seem to get the Instance-Home stuff to work right without local
start scripts in each directory. Right below the $INSTANCE_HOME/start
is the line I'd like to use to simplify the management of the
instances.
Can't get stop to work right. First 'stop' is not an instance, then
the first instance does appear to get stopped, but it errors on the
other two.
I get a 'start0' for the value of $WAIT in the starting text display.
(should just be a big fat zero or one!)
And for some reason, the script dumps the entire local environment to
the display before it does anything; any ideas why?
All constructive criticism welcome, and I'll take some flames
(high of 22 today).
System is RedHat-9.0 Zope-2.6.2 Python-2.2.3
Zope is installed in /usr/local/zope
Instances are /var/zope-sites/
Here's the script:
#!/bin/sh
# /etc/init.d/zope-instances
#
# Starts or stops multiple instances of zope one by one or all at ones.
# Configuration is done all through one configuration file
# /etc/zope-instances.conf which defines the location of the data-files,
# the user to run the instance, FTP portnrs, number of threads and if
the
# zdaemon should be used (to start a new instance should the one crash)
# all configurable per instance.
#
# Steps for creating and running a new instance:
# - start with a normal working (fresh) distribution of Zope
# ... snip ...
# - edit /etc/zope-instances.conf to run the new instance as you
desire
# - start the new instance (/etc/init.d/zope-instances start
instance-name)
#
# Note: this script is only tested for Red Hat distributions.
# Locations of scripts may vary from various distributions.
# Use at own risk.
#
# created: Chaim Zax (chaim at climbing.nl)
# version 0.02, dd. 29-3-'03
# version 0.02a, stuffduff 20-01-'04
INSTANCES_CONF=/etc/zope-instances.conf
DEFAULT_USER=www-data
ZOPE_BASE=/usr/local/zope
PS=ps wax
# Log- and pid-files
ZDAEMON_PIDFILE=/var/zProcessManager.pid
ZDAEMON_LOGFILE=/var/Z2_debug.log
ZOPE_PIDFILE=/var/Z2.pid
ZOPE_LOGFILE=/var/Z2.log
ZOPE_DEBUGFILE=/var/zope-debug.log
# Function for showing help-text how to use this script
helpText ()
{
echo Starts or stops multiple instances of zope one by one or all
at
ones.
echo
echo zope-instance [start/stop/restart/info/kill] [instance-name]
[-w] [-h]
echo
echo start/stop: starts or stops one or all
zope-instances
echo restart : restarts one or all zope-
instances
echo info : gets instance info as well as
their
current status
echo kill : kills one or all zope-instances,
even if orphaned
echo USE THIS ONLY WHEN ZOPE SPINS OUT
OF CONTROL
echo instance-name : if not provided or 'all'
indicates
all instances,
echo else acts only on the given
instance
echo -w: Do not wait for instance to
startup
echo -h: This help-text
}
startZope ()
{
startingAndStopping start $1 $2
}
stopZope ()
{
startingAndStopping stop $1 -
}
restartZope ()
{
startingAndStopping restart $1 $2
}
infoZope ()
{
startingAndStopping info $1 -
}
killZope ()
{
if [[ $1 == all ]]; then
killAll
else
killInstance $1
fi
}
# Start one or more instances depending of $1 and $2
startingAndStopping ()
{
MODE=$1 # mode is 'start', 'restart', 'stop' or 'info'
INSTANCE=$2
WAIT=$3
if [ ! -e $INSTANCES_CONF ]; then
echo ERROR: No configuration file '$INSTANCES_CONF'
exit 1
fi
SETUP=no
# sift through the configuration file, one line at a time
while read LINE; do
if [[ ${LINE::1} != # ]]; then
set $LINE
if [[ $1 != ]]; then
# starts, restarts or stops all instances (one per loop)
if [[ $INSTANCE == all ]]; then
STARTUP_MODE=$8
if [[ $STARTUP_MODE == 'start' || ($MODE != 'start' $MODE
!= 'restart') ]]; then
actionOnInstance $MODE $1 $2 $3 $4 $5 $6 $7 $8 $WAIT
fi
SETUP=done
# starts or stops only the provided instance and breaks out of
the loop
elif [[ $INSTANCE == $1 ]]; then
actionOnInstance $MODE $1 $2 $3 $4 $5 $6 $7 $8 $WAIT
SETUP=done
break
fi
fi
fi
done $INSTANCES_CONF
# the instance-name doesn't correspond to the ones in the
configuration file
if [[ $SETUP == no ]]; then
echo ZOPE-INSTANCE NOT STARTED/STOPPED! No instance found with
name'$INSTANCE'. Check the configuration file ($INSTANCES_CONF).
echo Possible options are:
echo - all (for starting and stopping all zope instances below)
cat $INSTANCES_CONF | awk '{ print -
[Zope-dev] RFC: backward compatibility of PythonScript bindings for 2.6.4 / 2.7.0
Hi all - We recently made Zope 2.6.4-rc1 and 2.7.0-rc1 releases which fix a number of issues that were introduced in the Q4 security audit work and the resulting 2.6.3 and 2.7.0-b4 releases. The initial feedback is very good, and at this point I am aware of only one outstanding issue - but it is a sticky one and I want to get some community feedback before deciding exactly how to address it. Background: one of the holes fixed in the security audit was that the current user's access to 'context' and 'container' in a Python Script was not checked when those names were bound to the script for execution. This meant that theoretically a script could have a handle to an object (like the script container) that the user really didn't have permission for. Subsequent attribute accesses or attempted method calls would likely still fail since a security check *would* be performed on those actions, but in principle the script shouldn't have been allowed to get that initial handle to the object. The fix for this was straightforward - do a security check on 'context' and 'container' before binding those objects when the script is getting ready to execute. While this is definitely the Right Thing To Do (tm) from a security standpoint, it poses a bit of a backwards compatibility problem because: - By default, all Python Scripts bind both 'context' and 'container'. This means that all existing Python Scripts in applications, portal tools, etc. have those bindings unless they have been manually changed. - A standard CMF / Plone idiom is to put scripts inside of portal tools (workflow is a primary example). Very often the users who execute the scripts (as a part of workflow, for example) **do not have access to the tool containing the scripts**. These two facts did not cause a problem before, because the security check for the 'container' binding was not being performed at bind-time. Now that it is, many scripts will not work because the user will not have access to the tool containing the script. Worse, the binding check will cause an unauthorized error **even if the script doesn't actually use the 'container' variable, because all existing Python Scripts already have that binding defined by default ;( So as things stand, the way the binding check currently works will cause problems for most everyone using a workflow tool or other tools containing scripts where the user doesn't have access to the script container (the tool itself). This is likely to be a fairly large number of people / sites. I'd like to propose a solution that will hopefully affect far fewer people, while still doing the right thing with regard to security. Currently, if the executing user does not have access to either 'context' or 'container', an Unauthorized exception will be raised at bind-time. *This will happen even if the script does not use either of those names*, which is the root of the problem. I propose to change that behavior so that if the security check on either 'context' or 'container' fails, that name will be bound to None rather than raise an Unauthorized. The effect of that change on existing sites would be: - Existing scripts living in tools which *don't* reference 'container' in their code will continue to work as before without any changes on the part of the site admin - Existing scripts that *do* refer to 'container' in their code (and if the user doesn't have access to it) will break, since 'container' will now be 'None' rather than what the script thought it would be. The fix for such sites is to make sure the user has the appropriate access on the script container. What I like about this is that it potentially requires direct action from fewer site admins. IOW, you only have to fix your permissions if you were already doing something that the security system should have been preventing before. What I don't like is that it is somewhat magical, and now the error you would get (probably 'None has no attribute xxx') if the user doesn't have access to the container doesn't tell you the real problem. That is likely to be compounded by the fact that some site admins will be saved from having to care immediately by this magic, then run into it later, when they might be thoroughly confused if they didn't happen to read this thread as it went by ;) The alternative is to take the 'hard-line' and say that site admins need to visit their script containers and ensure that either a) the users of the scripts have the appropriate permissions on the container or b) they remove the 'container' binding from their scripts if it is not appropriate to give the users access to the script container. Sorry this was so long, but I think these kinds of backward compatibility vs. consistency conundrums require some community buy-in on the path chosen, since *someone* will be unhappy and have to do some manual
Re: [Zope-dev] Zope Start Script Woes
I'm no big shell scripter, some suggestions anyway...
* I think you might be missing an INSTANCE_HOME parameter here,
something like
# what we'd like but won't recognize instance home
# exec /usr/bin/python $ZOPE_BASE/z2.py -z $ZOPE_BASE -u $USER \
# -w $HTTP_PORT -f $FTP_PORT -t $THREADS -Z $MANAGER \
# -l $INSTANCE_HOME$ZOPE_LOGFILE \
INSTANCE_HOME=$INSTANCE_HOME \
# -D $@ $INSTANCE_HOME/var/startup.log
or export the INSTANCE_HOME
* Are you shure you want to start Zope in debug mode?
* You might want to check
http://zope.org/Documentation/Books/ZopeBook/2_6Edition/MaintainingZope.stx
, I put some (very much simpler) startup scripts there
* Finally, the upcoming Zope 2.7 should behave much better wrt this (if
thats any help to you :-))
- peter.
Sean Duffy wrote:
Hi,
These are probably more shell scripting issues, but I'm hoping that
some scripter with an agile mind will show me the error of my ways,
so here goes.
I have borrowed a script from the zope site and modified it for my
purposes, and it 'sort of' works. The issues are:
Can't seem to get the Instance-Home stuff to work right without local
start scripts in each directory. Right below the $INSTANCE_HOME/start
is the line I'd like to use to simplify the management of the
instances.
Can't get stop to work right. First 'stop' is not an instance, then
the first instance does appear to get stopped, but it errors on the
other two.
I get a 'start0' for the value of $WAIT in the starting text display.
(should just be a big fat zero or one!)
And for some reason, the script dumps the entire local environment to
the display before it does anything; any ideas why?
All constructive criticism welcome, and I'll take some flames
(high of 22 today).
System is RedHat-9.0 Zope-2.6.2 Python-2.2.3
Zope is installed in /usr/local/zope
Instances are /var/zope-sites/
Here's the script:
#!/bin/sh
# /etc/init.d/zope-instances
#
# Starts or stops multiple instances of zope one by one or all at ones.
# Configuration is done all through one configuration file
# /etc/zope-instances.conf which defines the location of the data-files,
# the user to run the instance, FTP portnrs, number of threads and if
the
# zdaemon should be used (to start a new instance should the one crash)
# all configurable per instance.
#
# Steps for creating and running a new instance:
# - start with a normal working (fresh) distribution of Zope
# ... snip ...
# - edit /etc/zope-instances.conf to run the new instance as you
desire
# - start the new instance (/etc/init.d/zope-instances start
instance-name)
#
# Note: this script is only tested for Red Hat distributions.
# Locations of scripts may vary from various distributions.
# Use at own risk.
#
# created: Chaim Zax (chaim at climbing.nl)
# version 0.02, dd. 29-3-'03
# version 0.02a, stuffduff 20-01-'04
INSTANCES_CONF=/etc/zope-instances.conf
DEFAULT_USER=www-data
ZOPE_BASE=/usr/local/zope
PS=ps wax
# Log- and pid-files
ZDAEMON_PIDFILE=/var/zProcessManager.pid
ZDAEMON_LOGFILE=/var/Z2_debug.log
ZOPE_PIDFILE=/var/Z2.pid
ZOPE_LOGFILE=/var/Z2.log
ZOPE_DEBUGFILE=/var/zope-debug.log
# Function for showing help-text how to use this script
helpText ()
{
echo Starts or stops multiple instances of zope one by one or all
at
ones.
echo
echo zope-instance [start/stop/restart/info/kill] [instance-name]
[-w] [-h]
echo
echo start/stop: starts or stops one or all
zope-instances
echo restart : restarts one or all zope-
instances
echo info : gets instance info as well as
their
current status
echo kill : kills one or all zope-instances,
even if orphaned
echo USE THIS ONLY WHEN ZOPE SPINS OUT
OF CONTROL
echo instance-name : if not provided or 'all'
indicates
all instances,
echo else acts only on the given
instance
echo -w: Do not wait for instance to
startup
echo -h: This help-text
}
startZope ()
{
startingAndStopping start $1 $2
}
stopZope ()
{
startingAndStopping stop $1 -
}
restartZope ()
{
startingAndStopping restart $1 $2
}
infoZope ()
{
startingAndStopping info $1 -
}
killZope ()
{
if [[ $1 == all ]]; then
killAll
else
killInstance $1
fi
}
# Start one or more instances depending of $1 and $2
startingAndStopping ()
{
MODE=$1 # mode is 'start', 'restart', 'stop' or 'info'
INSTANCE=$2
WAIT=$3
if [ ! -e $INSTANCES_CONF ]; then
echo ERROR: No configuration file '$INSTANCES_CONF'
exit 1
fi
SETUP=no
# sift through the configuration file, one line at a time
while read LINE; do
if [[ ${LINE::1} != # ]]; then
set $LINE
if [[ $1 != ]]; then
# starts, restarts or stops all instances (one per loop)
if [[ $INSTANCE == all ]]; then
STARTUP_MODE=$8
if [[ $STARTUP_MODE == 'start'
Re: [Zope-dev] RFC: backward compatibility of PythonScript bindings for 2.6.4 / 2.7.0
On Wed, 2004-01-21 at 10:42, Brian Lloyd wrote: What I don't like is that it is somewhat magical, and now the error you would get (probably 'None has no attribute xxx') if the user doesn't have access to the container doesn't tell you the real problem. What if you used a special object that would produce a useful error message if the user tries to access the container. Assuming an access involves an attribute access: class UnauthorizedContext: def __getattr__(self, attr): raise Unauthorized(user does not have access to context) I'm sure the details aren't right, but I think the idea is clear enough. Jeremy ___ 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] Re: RFC: backward compatibility of PythonScript bindings for 2.6.4 / 2.7.0
Jeremy Hylton wrote: What if you used a special object that would produce a useful error message if the user tries to access the container. I like this. Make it a singleton, and put it in the global namespace for Scripts, so that we can write: if context is Inaccessible: # Do without access to context Cheers, Evan @ 4-am ___ 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] RFC: backward compatibility of PythonScript bindings for 2.6.4 / 2.7.0
On Wed, Jan 21, 2004 at 10:42:11AM -0500, Brian Lloyd wrote: These two facts did not cause a problem before, because the security check for the 'container' binding was not being performed at bind-time. One question - what *is* bind time? Is the container bound when the script is called? -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's THE PIDDLE! (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 )
[Zope-dev] Re: RFC: backward compatibility of ps bindings RESOLUTION
Jeremy Hylton wrote: What if you used a special object that would produce a useful error message if the user tries to access the container. I like this. Make it a singleton, and put it in the global namespace for Scripts, so that we can write: if context is Inaccessible: # Do without access to context I've checked in the changes to the 2.6 branch, 2.7 branch and the head to change the binding behavior for 'container' and 'context': - If the user does not have access to the item, the script will bind an UnauthorizedBinding object instead of the real object, rather than throw an exception at binding time. - Any attribute or item access on the UnauthorizedBinding will throw an Unauthorized, including the name of the binding that the user didn't have access to. The result is that if you have scripts where the script container is inaccessible to the users of the script: - If the script does not reference 'container' in its code, things will work without any action on the part of the site admin - If the script *does* reference 'container' then a meaningful Unauthorized error will be raised. Site admins can either give users the appropriate roles on the script container or give appropriate proxy roles to the scripts to fix any problems. Note that I *didn't* put the UnauthorizedBinding in the script globals to implement the Inaccessible idea above, because: - it is kind of 'featurish', at least in that it really should have some associated documentation etc. - I want to make only absolutely necessary changes at this point and get 2.6.4 and 2.7.0 finalized. If any of the Plone folk who have been running into this issue can try the changes from cvs, I'd appreciate it. 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] RFC: backward compatibility of PythonScript bindingsfor 2.6.4 / 2.7.0
These two facts did not cause a problem before, because the security check for the 'container' binding was not being performed at bind-time. One question - what *is* bind time? Is the container bound when the script is called? Yes - all of the bindings are figured out at the time the script is called. 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 bindings RESOLUTION
On Wed, Jan 21, 2004 at 02:06:24PM -0500, Brian Lloyd wrote: I've checked in the changes to the 2.6 branch, 2.7 branch and the head to change the binding behavior for 'container' and 'context': - If the user does not have access to the item, the script will bind an UnauthorizedBinding object instead of the real object, rather than throw an exception at binding time. - Any attribute or item access on the UnauthorizedBinding will throw an Unauthorized, including the name of the binding that the user didn't have access to. This sounds reasonable. Are you going to do another set of RC releases? I'd like to run our dev environment on 2.6.4-RCx for a day or two but I don't know when I'll be able to set it up. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's IN TEMPESTUOUS LEGIONAIRE! (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 )
[Zope-dev] Resolved security-related collector issues for the public?
Hi, 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. Lots of security-stuff is fixed now, but I don't think that all people will migrate their servers as soon as possible (due to limited time, the experience of the Zope-2.6.3-desaster, vacations, etc.pp.). With all the mentioned security-exploits in the collector out there, the probability of attacks will rise. And I don't think that this will shed a good light on Zope. My proposal: Can we have a delay for making security-related fixes public? Just a month or two or so... 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 )
Re: [Zope-dev] Re: RFC: backward compatibility of ps bindings RESOLUTION
Brian Lloyd wrote:
Jeremy Hylton wrote:
What if you used a special object that would produce a useful error
message if the user tries to access the container.
I like this. Make it a singleton, and put it in the global namespace
for Scripts, so that we can write:
if context is Inaccessible:
# Do without access to context
I've checked in the changes to the 2.6 branch, 2.7 branch and the head
to change the binding behavior for 'container' and 'context':
- If the user does not have access to the item, the script
will bind an UnauthorizedBinding object instead of the
real object, rather than throw an exception at binding
time.
- Any attribute or item access on the UnauthorizedBinding will
throw an Unauthorized, including the name of the binding
that the user didn't have access to.
The result is that if you have scripts where the script container
is inaccessible to the users of the script:
- If the script does not reference 'container' in its code,
things will work without any action on the part of the site
admin
- If the script *does* reference 'container' then a meaningful
Unauthorized error will be raised. Site admins can either
give users the appropriate roles on the script container or
give appropriate proxy roles to the scripts to fix any
problems.
Note that I *didn't* put the UnauthorizedBinding in the script
globals to implement the Inaccessible idea above, because:
- it is kind of 'featurish', at least in that it really should
have some associated documentation etc.
- I want to make only absolutely necessary changes at this
point and get 2.6.4 and 2.7.0 finalized.
If any of the Plone folk who have been running into this issue
can try the changes from cvs, I'd appreciate it.
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 )
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
___
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] RFC: backward compatibility of PythonScript bindings for 2.6.4 / 2.7.0
Jeremy Hylton wrote at 2004-1-21 11:44 -0500: On Wed, 2004-01-21 at 10:42, Brian Lloyd wrote: What I don't like is that it is somewhat magical, and now the error you would get (probably 'None has no attribute xxx') if the user doesn't have access to the container doesn't tell you the real problem. What if you used a special object that would produce a useful error message if the user tries to access the container. Assuming an access involves an attribute access: class UnauthorizedContext: def __getattr__(self, attr): raise Unauthorized(user does not have access to context) I'm sure the details aren't right, but I think the idea is clear enough. +1 -- Dieter ___ 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?
Maik Jablonski wrote: Normaly security-related stuff is not visible for the public... and this seems to be good to avoid exploits etc. Hiding the bugs doesn't avoid anything, it just leaves zope administrators helpless in the dark. I'm not going to rehash the arguments for and against full dislosure, but seriously--don't delude yourself into thinking that a problem goes away if you shut your eyes tightly enough. Lots of security-stuff is fixed now, but I don't think that all people will migrate their servers as soon as possible (due to limited time, the experience of the Zope-2.6.3-desaster, vacations, etc.pp.). Sure, thats true of every security hole. With all the mentioned security-exploits in the collector out there, the probability of attacks will rise. And I don't think that this will shed a good light on Zope. meh. Good, bad, its irrelevant, but you can't pretend there weren't problems and expect anyone with a shred of a clue to take you seriously. If you want to establish trust, you can be honest with your community, or you can do a lot of hand waving trying to cover things up and make yourself look even worse. My proposal: Can we have a delay for making security-related fixes public? Just a month or two or so... Every hole thats been fixed has been publically known and detailed for well over 4 months at the latest, with the exceptions of: 615 1154 - sessioning machinery was losing security context 924 - object properties stored as unprotected mutables All the unrestricted operations in RestrictedPython that were found as a result of ZC's security audit. (And possibly the unicode crashing issue, which I think got discussed on a public list or something fairly recently.) Delays are pointless. The broken sessioning machinery was sitting in the collector for a year and 3 months. During that time 2 different people uncovered the issue (presumebly) independantly, and reported it. How many uncovered it and didn't report it? How exactly was ZC supposed to release a new version of Zope with the fixes but at the same time not divulge the nature of the security flaws? Release an obsfucated binary distribution and say Trust Us? That doesn't sound very much like open source. -- Jamie Heilman http://audible.transient.net/~jamie/ You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid. -Buddy ___ 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] Re: Resolved security-related collector issues for the public?
Hi Jamie, Jamie Heilman wrote: Hiding the bugs doesn't avoid anything, it just leaves zope administrators helpless in the dark. ... How exactly was ZC supposed to release a new version of Zope with the fixes but at the same time not divulge the nature of the security flaws? Release an obsfucated binary distribution and say Trust Us? That doesn't sound very much like open source. In the past we had something like Hotfixes for security problems... Easy to install for the average administrator and that's it. I can check out the current Zope from a CVS... So getting security fixes is no problem for me. But I'm not an average Zope-Admin or -User. There are many admins / users out there who aren't able to do this (maybe they should learn it, but that's another point). Installing Zope 2.6.3 was a big mess (even renaming in the ZMI was broken) and most people rolled back to 2.6.2. Some people run even 2.5.1 (lots of Debian-Users etc.). If we don't have a easy-to-install-security-fix for such people (or a so called stable release, which works out of the box) we should a little bit cautious about releasing exploits. That's my point... 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 )
Re: [Zope-dev] Re: Resolved security-related collector issues for the public?
Maik Jablonski wrote: There are many admins / users out there who aren't able to do this (maybe they should learn it, but that's another point). Installing Zope 2.6.3 was a big mess (even renaming in the ZMI was broken) and most people rolled back to 2.6.2. Some people run even 2.5.1 (lots of Debian-Users etc.). Debian users who continue to use the 2.5.1 packages are being done an injustice, I agree, and its too bad, but the Debian security policy fails when a maintainer takes on a package they can't keep up with and the security team isn't able to step in and cover for them. It happens, the answer is usually to either find a new maintainer who can keep up, or remove the package from Debian. One of Debian's strengths though is that they don't hide this information, users are encouranged to review the bug tracking system to get a feel for a package's relative stability and weigh the risks on their own. If we don't have a easy-to-install-security-fix for such people (or a so called stable release, which works out of the box) we should a little bit cautious about releasing exploits. That's my point... So you want to offer aide to the people who've bitten off more than they can chew, and your proposed solutions seem to be either: a) provide easy-to-swallow security fixes timely vulnerability disclosure b) provide neither Given that ZC clearly doesn't have the resources available to do (a), irrespective of if its even technically feasible, we can rule it out. And (b), well (b) just screws everybody. Exploits are a byproduct of understanding the vulnerability, they're a natural part of experimentation and learning. You usually can't discuss a vulnerabilty without implying the exploit. If you really want to help people who can't help themselves, offer education, not censorship in the guise of protection. -- Jamie Heilman http://audible.transient.net/~jamie/ ...and no, I don't support the War On Terror. ___ 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 for the public?
Jamie Heilman wrote Given that ZC clearly doesn't have the resources available to do (a), irrespective of if its even technically feasible, we can rule it out. And (b), well (b) just screws everybody. Exploits are a byproduct of understanding the vulnerability, they're a natural part of experimentation and learning. You usually can't discuss a vulnerabilty without implying the exploit. If you really want to help people who can't help themselves, offer education, not censorship in the guise of protection. Worse yet, hiding the security bugs mean that other people who might be motivated to supply fixes are unaware of the issue and cannot help. I'd be +1 on exposing the security bugs - maybe after 2 weeks so that critical security flaws have a chance to be fixed immediately. But it should be an automatic thing, not something that requires manual intervention. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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 thepublic?
Maik Jablonski wrote: Normaly security-related stuff is not visible for the public... and this seems to be good to avoid exploits etc. Jamie Heilman wrote: Hiding the bugs doesn't avoid anything, it just leaves zope administrators helpless in the dark. I'm not going to rehash the arguments for and against full dislosure, but seriously--don't delude yourself into thinking that a problem goes away if you shut your eyes tightly enough. 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. *Getting to that point* is what I'm afraid of :) There are pretty widely varying opinions on this, and historically as a community we've not yet found a good process to really resolve issues when there isn't a clear majority opinion. 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. While we at ZC try very hard to strike a delicate balance between transparency and risk management, doing so on a case-by-case basis is tough and there will *always* be some who disagree with the course chosen, no matter what it is. All in all, I think we'd better off having 'The Rules' regarding security reports, and working to make sure that we are all consistent in following them. 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 )
[Zope-dev] help me convert from j2ee to zope
Hi, I would like to stop developing with JBoss and convert to Zope. I have been able to figure most things out using the Zope website but I have a few questions... The majority of my code was in EJB's. So I am trying to create Zope products to replace them. What kind of naming service is available within Zope? For example, how can I get a reference to one object from another object within Zope? This would be the equivalent of a local interface in J2EE. In JBoss I would use a session bean as the remote user interface and it would manage entity beans. So in Zope if I have a non-persistent object as the XML-RPC published user interface, how can I have it access persistent objects within Zope? How can I create new objects programmatically in Zope? In J2EE I would get get a home interface to a bean and then call a create method on it to create the bean. I know how to create new objects using ZMI in Zope, but I need objects to be created through remote calls from clients. For example if I had objects that represent tasks in Zope, I need the clients to be able to create and delete tasks. How do I do that? Are there any other gotchas that ex J2EE developers can tell me about switching to Zope? I've read all the documentation I can find on the web site, so if I've missed something please point me to it. Thanks, -- Ryan Boder http://www.bitwiser.org/icanoop ___ 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?
On Wednesday 21 January 2004 03:21 pm, Jamie Heilman wrote: Hiding the bugs doesn't avoid anything, it just leaves zope administrators helpless in the dark. I'm not going to rehash the arguments for and against full dislosure, but seriously--don't delude yourself into thinking that a problem goes away if you shut your eyes tightly enough. Hear, hear! Consider also the position of someone who writes their own product code -- if potential exploits are know to exist with specific Zope functionality, it may be desireable to make design changes to compensate. Or at least, we know to pass that information on to users of our products. Not knowing puts us in a very uncertain position -- which I think is far worse for Zope's reputation than any specific set of known defects. What's more, that reputation may rub off on the rest of us. ;-) Uncertainty is the U in FUD, remember. Cheers, Terry ___ 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 )
