Re: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?)
On Friday 06 June 2003 21:28, Jamie Heilman wrote: Quick way to add 100 zodb connections and ~90M to the memory footprint with relatively little clue of who is responsible assuming traditional logging; presumeably one would get much trickier if they really wanted to obfuscate the source of attack, slowly crawling the site, changing the user-agent string, etc. Attached is a temporary patch to block this denial of service attack. This patch applies cleanly to the trunk and the 2.6 branch. This patch works by blocking all access to versions in the publisher, so dont apply it if you cant afford to stop using versions -- Toby Dickenson http://www.geminidataloggers.com/people/tdickensonIndex: lib/python/ZODB/ZApplication.py === RCS file: /cvs-repository/Zope/lib/python/ZODB/ZApplication.py,v retrieving revision 1.13 diff -c -2 -r1.13 ZApplication.py *** lib/python/ZODB/ZApplication.py 8 Apr 2003 18:48:22 - 1.13 --- lib/python/ZODB/ZApplication.py 9 Jun 2003 22:58:43 - *** *** 42,49 def __bobo_traverse__(self, REQUEST=None, name=None): ! db, aname, version_support = self._stuff ! if version_support is not None and REQUEST is not None: ! version=REQUEST.get(version_support,'') ! else: version='' conn=db.open(version) --- 42,53 def __bobo_traverse__(self, REQUEST=None, name=None): ! # Disable nasty insecure version support. Thanks to ! # Jamie Heilman and everyone one zope-dev ! # ! # db, aname, version_support = self._stuff ! # if version_support is not None and REQUEST is not None: ! # version=REQUEST.get(version_support,'') ! # else: version='' ! version = '' conn=db.open(version)
Re: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?)
On Tuesday 10 June 2003 09:32, Jamie Heilman wrote: Toby Dickenson wrote: ! # Disable nasty insecure version support. Thanks to ! # Jamie Heilman and everyone one zope-dev Unless you're damning me with faint praise for posting an exploit, (which is fine) No criticism was implied public exploits are valuable part of the security process. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson ___ 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: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?)
Toby Dickenson wrote: No criticism was implied public exploits are valuable part of the security process. Its nice to hear not everyone in the industry has lost their mind. /me glances at redmond -- Jamie Heilman http://audible.transient.net/~jamie/ We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure. -Rosencrantz ___ 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: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?)
FYI - we plan for this to be fixed in 2.6.2, preferably by fixing the version machinery to require the join / leave versions permission (which is assigned only to managers by default. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Oliver Bleutgen Sent: Tuesday, June 10, 2003 7:35 AM To: [EMAIL PROTECTED] Subject: Re: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?) Chris Withers wrote: Shane Hathaway wrote: My opinion on this is a little different. It's quite easy for anyone to make mischief on any Zope server that lets people make even minor changes to the site, such as giving feedback, posting a discussion item, etc. On the weekend I had the idea that it's even easier. See http://zope.nipltd.com/public/lists/dev-archive.nsf/ByKey/D1CAAEC689AB7BA9 how to do that on an zope server. All you have to do is include a Zope-Version cookie in the request and your changes will place a lock on any objects that the request touches. Zope doesn't even check the validity of the Zope-Version cookie. Anyone who is not a ZODB expert would have a hard time bringing the site back to sanity. This was my fear, and it's pretty shocking. Maybe Oliver should do just such a thing on both collector.zope.org and zope.org, or maybe cbsnewyork.com to prove a point and then this issue will get the attention is deserves ;-) Yeah, and I'm sure I'd get personal attention too, in a way I'd prefer not to get ;). cheers, oliver ___ 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 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: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?)
One man's opinion: - Version support (at the application level) should be optional in 2.7. You should be able to turn it off (maybe through ZConfig). The default should probably be off, since I think more people avoid them than use them. I would suggest these approaches: 1: File a bug in the collector and be prepared to wait an indefinite time for it to be acted upon. 2: develop a patch and submit it and/or check it in probably after vetting the change on a branch. I'm afraid the only way to get your favorite issue fixed quickly is to fix it yourself. The security implications do not seem dire enough to me to warrent trying to squeeze this into 2.6.x. If you do not use versions then none of the implications apply. Perhaps it might be possible to do additional security checks to make entering versions more protected. This might be an appropriate change for 2.6. -Casey On Friday 06 June 2003 05:46 am, Oliver Bleutgen wrote: Ok, I still have the impression that not enough people are aware of the full implications of the version functionality as it is implemented in zope. So let me summarize. versioning-as-implemented-in-zope consists of two parts: First, there's the database backend part (which I know nothing about) with a small glue layer (inside ZODB.ZApplication.ZApplicationWrapper). This resides where the db-connection is opened on the very start of every request. The second part is the Version product (capitalized to distinguish them) which is zope's mechanism to get a variable named 'Zope-Version' (==version_support) with the value of the path to the version object inside the REQUEST (by setting a cookie). Bad properties of this implementation: 1. The Join/Leave Versions permission doesn't secure entering versions 2. Zope doesn't care if a correspondending Version instance to the value of REQUEST['Zope-Version'] exists, more exactly, zope doesn't care for the value of that Zope-Version variable at all. 3. And (minor problem, but whatever), since zope relies completely on the browser to send cookies only the right time (i.e. that the path set for the cookie must match a prefix of the request-URI), this might also give unexpected results with acquisition. Security implications: Doh, anybody who can read/write to a zope server can get it to read/write from/to any version he likes, and the admin has no way of anticipating that short of patching zope. Combine that with sites like squishdot, collector.zope.org and you get chaos. Big plea: Really, this _is_ a security bug, and it should be handled that way and fixed in 2.6.2 by any meansm, so that all(!) bad properties I listed above are gone. Sorry for getting a bit worked up about that issue. cheers, oliver ___ 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 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: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?)
On Friday 06 June 2003 15:04, Shane Hathaway wrote: I think 2.6 ought to fix this by disabling recognition of the Zope-Version cookie Setting this individually for each http port would better support existing happy users of this feature. (Im sure there must be some ;-) Being able to set up a port that ignored cookies but always used a specific Version would avoid many of the existing problems too. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson ___ 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: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?)
Oliver Bleutgen wrote: 2. Zope doesn't care if a correspondending Version instance to the value of REQUEST['Zope-Version'] exists, more exactly, zope doesn't care for the value of that Zope-Version variable at all. Hmm, it doesn't care, but it does store it in memory. Pardon my fugly non-portable bashisms here, but I just wanted to hash out an example: #!/path/to/bash exec /dev/null h='http://victim.example.com/' for i in `seq 100`; do w3m -dump -post (perl -e 'print Zope-Version=,$ARGV[0]x50' $i) $h done Quick way to add 100 zodb connections and ~90M to the memory footprint with relatively little clue of who is responsible assuming traditional logging; presumeably one would get much trickier if they really wanted to obfuscate the source of attack, slowly crawling the site, changing the user-agent string, etc. Under sane resource limits the host is spared however the /Control_Panel/Database/manage_cacheParameters resource becomes unavailable due to memory constraints. Other side-effects from allowing anonymous clients to open additional zodb connections are as of yet unknown to me, anyone care to speculate on other vectors of abuse? -- Jamie Heilman http://audible.transient.net/~jamie/ We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure. -Rosencrantz ___ 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 )
