RE: [Zope] Urgent help needed: Zope falls over under moderate loa d
Zope's http implementation is *not* *robust* enough to be exposed to the raw internet. It has a number of serious, and fairly obvious denial-of-service vulnerabilities.
Toby, are these vulnerabilities in the collector? If not, and you've got the time, could you put them in there?
Some of them were in the old collector. I dont think it would be humanly possible to list them all. Its more than a few bugs which individually may be fixable... Zope's http layer simply wasnt designed with this kind of robustness in mind, and its only a small exaggeration to say that *everything* is wrong. Also, Im not sure its worth the effort. This isnt the only compelling reason for using a font-end proxy. Using a proxy makes this problem a non-issue, so why bother fixing it?
Zope's http layer simply wasnt designed with this kind of robustness in mind, and its only a small exaggeration to say that *everything* is wrong.
Maybe it wasn't designed for it, but it's being used as if it was. ;-)
Also, Im not sure its worth the effort. This isnt the only compelling reason for using a font-end proxy. Using a proxy makes this problem a non-issue, so why bother fixing it?
Well, I'm not sure what "it" is, yet, so I don't have a sense of the cost involved. If there is a bit of low-handing fruit that takes away some of the brokkenness, it'd be nice to put in.. But it'd also be nice to have a reasonable HTTP implementation. It's conceivable that a proxy could tickle one of these bugs just as well as a user, no? I'm sure that Sam Rushing would like to know if there are problems with Medusa as well. -- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones"
On Wed, 21 Nov 2001 10:31:42 -0500, Chris McDonough <chrism@digicool.com> wrote:
Zope's http layer simply wasnt designed with this kind of robustness in mind, and its only a small exaggeration to say that *everything* is wrong.
Maybe it wasn't designed for it, but it's being used as if it was. ;-)
mmm. Im a bit out of touch with adminstrators documentation. Does it raise these issues?
Also, Im not sure its worth the effort. This isnt the only compelling reason for using a font-end proxy. Using a proxy makes this problem a non-issue, so why bother fixing it?
Well, I'm not sure what "it" is, yet, so I don't have a sense of the cost involved. If there is a bit of low-handing fruit that takes away some of the brokkenness, it'd be nice to put in..
I recall a couple of the details.... It collects HTTP headers in memory until the headers head. An attacker can consume all memory by sending endless headers. Additionally, it builds up the headers by appending what is read to a string. An attacker can consume all processor time by sending headers one byte at a time, since string appends are O(n*n). There were some other problems too, plus, as I mentioned, a general feeling that it wasnt designed to do this job.
It's conceivable that a proxy could tickle one of these bugs just as well as a user, no?
Im most familiar with squid, which goes to some lengths to eliminate such silliness from the http conversation. Last time I look at this, I was satisfied that squid was good enough for me. Of course when it comes to bugs, never say never. Toby Dickenson tdickenson@geminidataloggers.com
Im a bit out of touch with adminstrators documentation. Does it raise these issues?
Err... administrators documentation? We only wish.
There were some other problems too, plus, as I mentioned, a general feeling that it wasnt designed to do this job.
I put both of these bugs back in to the collector, thanks! If you remember more, please stick them in there.
Im most familiar with squid, which goes to some lengths to eliminate such silliness from the http conversation. Last time I look at this, I was satisfied that squid was good enough for me.
All the same, it'd still be nice to have a reasonable HTTP implementation. As I haven't felt the pain of auditing the code, like you have, I'm perhaps more optimistic than you are about fixing what exists. - C
hi there, I am a little confused, after updating my zopeserver from 240 to 242 on linux redhat 7. The following code, which is needed in order to generate a sitemap, worked fine under 240, but not under 242! It is called "test" and does start itself: <dtml-var standard_html_header> <dtml-in "objectItems(['Portal Folder'])" skip_unauthorized> <dtml-try> <dt> <img src='misc_/OFSP/Folder_icon.gif' border=0> <dtml-var id> </dt> <dtml-with sequence-item> <dtml-var test> </dtml-with> <dtml-except></dtml-try> </dtml-in> <dtml-var standard_html_footer> In Zope 242 I get the error: Error Type: KeyError Error Value: validate Perhabs someone is able to help me ?!?!?! Thanks a lot in advance, ... Marc -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
if it's the error i am thinking of (you did not provide the full traceback so i don't know) using 2.4.3 instead of 2.4.2 will help you. jens On Wednesday, November 21, 2001, at 10:30 , Marc Fischer wrote:
hi there,
I am a little confused, after updating my zopeserver from 240 to 242 on linux redhat 7.
The following code, which is needed in order to generate a sitemap, worked fine under 240, but not under 242!
It is called "test" and does start itself:
<dtml-var standard_html_header>
<dtml-in "objectItems(['Portal Folder'])" skip_unauthorized>
<dtml-try> <dt> <img src='misc_/OFSP/Folder_icon.gif' border=0> <dtml-var id> </dt> <dtml-with sequence-item> <dtml-var test> </dtml-with> <dtml-except></dtml-try> </dtml-in> <dtml-var standard_html_footer>
In Zope 242 I get the error:
Error Type: KeyError Error Value: validate
Perhabs someone is able to help me ?!?!?!
Thanks a lot in advance, ...
Marc
-- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
On Thursday 22 November 2001 00:56, Toby Dickenson wrote:
Zope's http implementation is *not* *robust* enough to be exposed to the raw internet. It has a number of serious, and fairly obvious denial-of-service vulnerabilities.
Toby, are these vulnerabilities in the collector? If not, and you've got the time, could you put them in there?
Some of them were in the old collector.
I dont think it would be humanly possible to list them all. Its more than a few bugs which individually may be fixable... Zope's http layer simply wasnt designed with this kind of robustness in mind, and its only a small exaggeration to say that *everything* is wrong.
Also, Im not sure its worth the effort. This isnt the only compelling reason for using a font-end proxy. Using a proxy makes this problem a non-issue, so why bother fixing it?
... because it requires the installation of Yet Another Piece Of Software, which can fail or otherwise go sideways in its own peculiar ways. Richard
On Thu, 22 Nov 2001 08:24:04 +1100, Richard Jones <richard@bizarsoftware.com.au> wrote:
Also, Im not sure its worth the effort. This isnt the only compelling reason for using a font-end proxy. Using a proxy makes this problem a non-issue, so why bother fixing it?
... because it requires the installation of Yet Another Piece Of Software, which can fail or otherwise go sideways in its own peculiar ways.
True But, that has to be balanced against the value which a front-end proxy brings to the zope configuration.... in other words, whether squid is pulling its weight. Zope relies on external software for email delivery, dns lookups, etc. These are complicated jobs that other software already handles well. I dont see the front-end job is any different. Toby Dickenson tdickenson@geminidataloggers.com
participants (7)
-
Chris McDonough -
Chris McDonough -
Jens Vagelpohl -
Marc Fischer -
Richard Jones -
Toby Dickenson -
Toby Dickenson