Re: [Zope-Coders] Re: [Zope-dev] DTML and REQUEST data changesabout to be checked in
> [Snip] > > I just want to keep the security worries in check. Let me ramble for a > bit... We've released a lot of hotfixes, but *none* of the > vulnerabilities could give an attacker root access, and none of them > could give console access to anonymous users AFAIK. All of the > vulnerabilities violated Zope's security policy, but Zope's security > policy is constrained by system security and other safeguards. People > outside the Zope community don't know that, so a lot have labeled Zope > as too insecure to use. The reality is that we've never even had an > exploitable buffer overrun. :-) We should avoid sending the wrong > message by making a hotfix for every little thing. > > Shane > I'd like to second this. It was one of the contibuting factors in the decision of my former employers to opt for spectra instead of a Zope solution (That already existed!!). I am sure there are other cases of this too... If someone finds a buffer overrun, fix it by all means, but other issues may be better left for minor version releases, where they can be buried in the changelog. Just my £0.02 Adrian... -- Adrian Hungate EMail: [EMAIL PROTECTED] Web: http://www.haqa.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DTML and REQUEST data changes about to be checkedin
On 8/9/02 8:43 AM, "Toby Dickenson" <[EMAIL PROTECTED]> wrote: > I agree it is true in most cases, but not all. Have you analysed how many > applications will be broken by this? how they can detect the breakage? I > certainly will not have time to assess the implications on my applications > before the scheduled release of 2.6. This is why I raised the flag of "can there be a way to disable it?", and Martijn put a fix in: - and &dtml.-name; will now automatically HTML-quote unsafe data taken implictly from the REQUEST object. Data taken explicitly from the REQUEST object is not affected, as well as any other data not originating from REQUEST. This can be disabled (at your own risk!) by setting the environment variable ZOPE_DTML_REQUEST_AUTOQUOTE to one of 'no', '0', or 'disabled'. I have the same concerns you do, but I figure that if any problems are found during normal execution of any Zope release this is attached to that I don't have time to investigate a fix for myself, I can add this environment variable (which normally I am not fond of doing), restart, and make a note "investigate fixing site blablabla". Is there any reason why this solution wouldn't work for you? > Like I said before, this is probably a good feature. If it was available as a > patch then I would probably use it on a number of my sites, and would > recommend it to others. I would be very happy see it (or something like it) > in 2.7. > > But not 2.6. Oh, 2.6 will never happen anyways ;) (seriously folks - what's the plan?). Since there's no current release plan for 2.6, it's hard to plan future deployments around it anyways. But if you have any sites you plan to move to 2.6, you should test this Autoquote change aggressively during the alpha/beta cycle. Since the ZOPE_DTML_REQUEST_AUTOQUOTE change has been put in, I've reserved future judgments until I get a chance to actually do some testing. I know that if I do run into any issues in the future that I don't have time to deal with, I can just flip that switch off. -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-Coders] Re: [Zope-dev] DTML and REQUEST data changesaboutto be checked in
Tres Seaver wrote:
> Whithout the fix, virtually every Zope site in the world is vulnerable
> to URL-based cross-site scripting exploits. For instance, any URL which
> contains invalid form variable marshalling can generate an error page
> which includes the erroneous value, unquoted. E.g.:
>
>
>http://somezopesite.com/looks/like/legitimate?foo:int=%3Cscript%3Ealert('Owned')%3C/script%3E>
I think an URL with an inconspicuous mispelling of the domain name is a
far greater vulnerability than cross-site-scripting.
Consider:
http://barnesandnohle.com/freebooks.html
An attacker could set up that misleading domain name then spam people to
order free books, requiring credit card info for some
"book-of-the-month" trick. Some simple scraping of the true site would
keep most people from ever thinking there was a problem. In fact, you
don't even have to misspell it:
http://barnes-andnoble.com/freebooks.html
This affects the entire web and every piece of software involved in it.
I just want to keep the security worries in check. Let me ramble for a
bit... We've released a lot of hotfixes, but *none* of the
vulnerabilities could give an attacker root access, and none of them
could give console access to anonymous users AFAIK. All of the
vulnerabilities violated Zope's security policy, but Zope's security
policy is constrained by system security and other safeguards. People
outside the Zope community don't know that, so a lot have labeled Zope
as too insecure to use. The reality is that we've never even had an
exploitable buffer overrun. :-) We should avoid sending the wrong
message by making a hotfix for every little thing.
Shane
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-Coders] Re: [Zope-dev] DTML and REQUEST data changes aboutto be checked in
Tres Seaver wrote:
> Martijn did add a knob to turn the feature off, via a new environment
> variable. With a security vulnerability, we have to come up with some
> kind of balance between the need to propagate the fix as quickly as
> possible and the need (as you point out) not to disrupt production sites
> unduly. I don't believe we can afford to wait a whole other release
> cycle for this fix; Brian, Jim, and Martijn deemed the fix too
> pervasive to be bundled as a hotfix, which offers us little choice
> except to included it in current releases.
>
> Whithout the fix, virtually every Zope site in the world is vulnerable
> to URL-based cross-site scripting exploits. For instance, any URL which
> contains invalid form variable marshalling can generate an error page
> which includes the erroneous value, unquoted. E.g.:
>
>
>http://somezopesite.com/looks/like/legitimate?foo:int=%3Cscript%3Ealert('Owned')%3C/script%3E>
Yeah,
but why not fixing that instead?
I for one concur that it is a good thing to care for such stuff, but the
way it is fixed might really lead to a lot of confusion, because it
again introduces some magic which happens behind the users back.
As far as I understand the fix, I can imagine some use cases which might
break without having been in danger at all. Someone please correct me if
I'm wrong.
1. Sending mails with dtml-sendmail
If you send plaintext mails, suddendly you get html_quoted stuff which
you never wanted. Having to debug this without knowing about the new
"feature" will get people up in arms.
2.
3. Any object which uses dtml to render content from the REQUEST not
meant for being displayed in a browser.
Some people might use zope for things which have nothing to do with
html, so they didn't care about cross-site scripting in the first place.
cheers,
oliver
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] DCOracle2 Binding Array
While using the DCOracle2 module outside of Zope I recieve the following traceback: Traceback (most recent call last): File "/dev/fd/4", line 206, in ? File "/dev/fd/4", line 206, in ? File "./modules/Calendar.py", line 193, in dayGroupView reservation = Reservation(conflict) File "./modules/Reservation.py", line 27, in __init__ self.load(id) File "./modules/Reservation.py", line 134, in load sth.execute(sql, id) File "/opt/python/2.2.1-update1/sparc-sunos5.8/lib/python2.2/site-packages/DCOracle2/DCOracle2.py", line 876, in execute return self.executemany(operation,p) File "/opt/python/2.2.1-update1/sparc-sunos5.8/lib/python2.2/site-packages/DCOracle2/DCOracle2.py", line 1036, in executemany baoa[c][br] = p OverflowError: Assigned value too large for Binding Array I have tried the SQL outside of python and it works fine. This also worked correctly before upgrading to DCOracle2. Any help? Thanks, -Brian ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-Coders] Re: [Zope-dev] DTML and REQUEST data changesabout to be checked in
On Fri, 2002-08-09 at 10:43, Toby Dickenson wrote:
> On Friday 09 Aug 2002 3:12 pm, Martijn Pieters wrote:
> > On Fri, Aug 09, 2002 at 09:56:45AM +0100, Toby Dickenson wrote:
> > > > The risk for breakage is very small really
> > >
> > > Your choice of '<' and html_quote suggests that my dtml code which
> > > generates javascript and vbscript carries a higher risk than dtml which
> > > generates html.
> >
> > Only if you generated that script using data from the REQUEST, implicitly.
>
> Yes
>
> > Which was bad in the first place.
>
> I agree it is true in most cases, but not all. Have you analysed how many
> applications will be broken by this? how they can detect the breakage? I
> certainly will not have time to assess the implications on my applications
> before the scheduled release of 2.6.
>
> > > >, and breakage
> > > > will generally only occur when someone is trying to exploit the
> > > > weakness, not in normal operation of the site.
> > >
> > > The fact that your change uses html_quote to 'fix' the problem rather
> > > than sounding 'hacker alert' alarm bells suggests to me that you dont
> > > really believe that ;-)
> >
> > Again, the wide scope of DTML use would make such bells warble prematurely
> > all too often.
>
> 'all too often' also contradicts your statements that this will not happen in
> normal operation of the site, and that the risk of breakage is 'very small'.
>
>
> Like I said before, this is probably a good feature. If it was available as a
> patch then I would probably use it on a number of my sites, and would
> recommend it to others. I would be very happy see it (or something like it)
> in 2.7.
>
> But not 2.6.
Martijn did add a knob to turn the feature off, via a new environment
variable. With a security vulnerability, we have to come up with some
kind of balance between the need to propagate the fix as quickly as
possible and the need (as you point out) not to disrupt production sites
unduly. I don't believe we can afford to wait a whole other release
cycle for this fix; Brian, Jim, and Martijn deemed the fix too
pervasive to be bundled as a hotfix, which offers us little choice
except to included it in current releases.
Whithout the fix, virtually every Zope site in the world is vulnerable
to URL-based cross-site scripting exploits. For instance, any URL which
contains invalid form variable marshalling can generate an error page
which includes the erroneous value, unquoted. E.g.:
http://somezopesite.com/looks/like/legitimate?foo:int=%3Cscript%3Ealert('Owned')%3C/script%3E>
Tres.
--
===
Tres Seaver[EMAIL PROTECTED]
Zope Corporation "Zope Dealers" http://www.zope.com
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DTML and REQUEST data changes about to be checked in
On Friday 09 Aug 2002 3:12 pm, Martijn Pieters wrote: > On Fri, Aug 09, 2002 at 09:56:45AM +0100, Toby Dickenson wrote: > > > The risk for breakage is very small really > > > > Your choice of '<' and html_quote suggests that my dtml code which > > generates javascript and vbscript carries a higher risk than dtml which > > generates html. > > Only if you generated that script using data from the REQUEST, implicitly. Yes > Which was bad in the first place. I agree it is true in most cases, but not all. Have you analysed how many applications will be broken by this? how they can detect the breakage? I certainly will not have time to assess the implications on my applications before the scheduled release of 2.6. > > >, and breakage > > > will generally only occur when someone is trying to exploit the > > > weakness, not in normal operation of the site. > > > > The fact that your change uses html_quote to 'fix' the problem rather > > than sounding 'hacker alert' alarm bells suggests to me that you dont > > really believe that ;-) > > Again, the wide scope of DTML use would make such bells warble prematurely > all too often. 'all too often' also contradicts your statements that this will not happen in normal operation of the site, and that the risk of breakage is 'very small'. Like I said before, this is probably a good feature. If it was available as a patch then I would probably use it on a number of my sites, and would recommend it to others. I would be very happy see it (or something like it) in 2.7. But not 2.6. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DTML and REQUEST data changes about to be checked in
On Fri, Aug 09, 2002 at 09:56:45AM +0100, Toby Dickenson wrote: > > The risk for breakage is very small really > > Your choice of '<' and html_quote suggests that my dtml code which generates > javascript and vbscript carries a higher risk than dtml which generates html. Only if you generated that script using data from the REQUEST, implicitly. Which was bad in the first place. > >, and breakage > > will generally only occur when someone is trying to exploit the weakness, > > not in normal operation of the site. > > The fact that your change uses html_quote to 'fix' the problem rather than > sounding 'hacker alert' alarm bells suggests to me that you dont really > believe that ;-) Again, the wide scope of DTML use would make such bells warble prematurely all too often. The normal, recommended fix for the general weakness is to always use HTML quote. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] __record_schema__ of Brains (Was: Record.pyd)
__record_schema__ is simply a dictionary which maps field names to column positions (ints) so that the record knows the index of each field in the record tuples. See line 154 of Catalog.py to see how it is initialized to the Metadata schema plus a few extra columns for catalog rid and scores. -Casey On Friday 09 August 2002 07:17 am, Johan Carlsson [Torped] wrote: > Hi, > I'm back on the Brain track :-) > What function does the __record_schema__ attribute of the Brains have? > > Does it do anything else when provide the has_key feature? > def has_key(self, key): > return self.__record_schema__.has_key(key) > > > Best Regards, > Johan Carlsson ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] __record_schema__ of Brains (Was: Record.pyd)
Hi, I'm back on the Brain track :-) What function does the __record_schema__ attribute of the Brains have? Does it do anything else when provide the has_key feature? def has_key(self, key): return self.__record_schema__.has_key(key) Best Regards, Johan Carlsson -- Torped Strategi och Kommunikation AB Johan Carlsson [EMAIL PROTECTED] Mail: Birkagatan 9 SE-113 36 Stockholm Sweden Visit: Västmannagatan 67, Stockholm, Sweden Phone +46-(0)8-32 31 23 Fax +46-(0)8-32 31 83 Mobil +46-(0)70-558 25 24 http://www.torped.se http://www.easypublisher.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DTML and REQUEST data changes about to be checked in
On Thursday 08 Aug 2002 9:29 pm, Martijn Pieters wrote: > On Thu, Aug 08, 2002 at 08:19:12PM +0100, Toby Dickenson wrote: > > > I am about to land some big changes in the way DTML deals with data > > > taken from the REQUEST object when accessed implicitly, in both the > > > Zope Trunk and the Zope 2.5 branch. > > > > In my opinion this change is completely unacceptable at this late stage > > of > > > > the release cycle. As you said: > > > These changes could potentially break existing Zope sites. > > > > The existing behavior might be flawed, but it is a flaw we have all lived > > with for a long time. In my opinion this needs: > > > > 1. To be deferred until the 2.7 cycle. > > > > 2. A detailed fishbowl proposal. > > Note that the problems fixed are potential security problems. Although we > cannot fix every site out there for sure, the fixes certainly dramatically > reduce the risks. Im not going to argue that this feature is bad - because I dont believe that to be true. I suspect the feature is not exactly quite right - but those issues can easily be resolved over a full release cycle. > The risk for breakage is very small really Your choice of '<' and html_quote suggests that my dtml code which generates javascript and vbscript carries a higher risk than dtml which generates html. >, and breakage > will generally only occur when someone is trying to exploit the weakness, > not in normal operation of the site. The fact that your change uses html_quote to 'fix' the problem rather than sounding 'hacker alert' alarm bells suggests to me that you dont really believe that ;-) > I'll leave any decisions on wether or not this stays in the current release > cycles or moves to 2.7 to Jim Fulton. He is unfortunately on cvacation > until next week. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
