September 2001 - Zope-Dev

Zope on Windows: enhancements proposed
by Richard Jones 25 Sep '01

25 Sep '01

We've got a wonderful zope control panel (which installs into the standard windows Control Panel) and zope service which we'll be making available in binary and source form this week. Like the Mac OS X controller, this is simply a trivial re-branding extension of our work in supporting the usability of our Bizar Shop product. The windows controller works on win95/win98/NT/win2k. It controls a "real" windows service on platforms were services are run (NT/win2k), and otherwise controls a "service daemon" which stays in the system tray. We'll call this service "Zope", and its job is to lauch "python [script] [args]" with some Zope-specific environment fiddling (INSTANCE_HOME env, cd ${SOFTWARE_HOME}, STUPID_LOG_FILE env). The current method of starting Zope as a windows service using PythonService.exe is kludgy, mostly because of the unnecessary layer of python. The Zope binary distribution's use of PythonService.exe does the same thing that our Zope service does (in the end), which is to lauch "python z2.py [args]". We'd like to propose that the service distributed with Zope move over to using our code. Our control panel will be able to control "Zope (WebSite)", but we probably won't offer the ability to configure it (editing the z2[s].py file in-place is possible - we do that now - but it's rather hackish). So, best scenario is that Zope ships with the controller and our service. Worst scenario is that the controller is downloaded separately and can only stop/start PythonService. In the second case, we'd still ship our service and install it - meaning that there'd be two Zope services in the service manager, but at least the controller, which appears in the control panel, would still be able to fully control Zope. As a separate issue - we're curious about the naming of the Zope installation - why is it called WebSite (and the Zope service "Zope (WebSite)")? The name clashes with another product that's fairly well-known in the windows community originally from O'Reilly: http://www.oreilly.com/software/index.html ... and since Zope is a fairly distinctive name ... Richard ps. happy to put this up as a project if required.

2 3

apache ProxyPass and REMOTE_ADDR -- any further discussion or
by Joseph Wayne Norton 25 Sep '01

25 Sep '01

consensus? User-Agent: Wanderlust/2.5.8 (Smooth Criminal) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 MULE XEmacs/21.4 (patch 1) (Copyleft) (i386-debian-linux) Reply-To: norton(a)alum.mit.edu MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Hello. I have put together a patch (see below) which adds the necessary support for performing user authentication based on domain (and logging) if your zope server is hiding behind apache+mod_proxy+mod_proxy_add_forward. I noticed a posting to zope-dev early this year regarding apache ProxyPass and SiteAccess http://aspn.activestate.com/ASPN/Mail/Message/zope-Dev/479449 Has there been any further discussion or consensus on this issue? regards, - joe n. *** Zope-2.4.1-src/ZServer/HTTPServer.py Wed Aug 8 22:04:32 2001 --- zope-2.4.1/ZServer/HTTPServer.py Tue Sep 25 12:01:55 2001 *************** *** 294,299 **** --- 294,315 ---- if value and not env_has(key): env[key]=value env.update(self.env_override) + + # set REMOTE_ADDR_X and REMOTE_HOST_X + if env_has('HTTP_X_FORWARDED_FOR'): + # only fetch last addr -- appended by mod_proxy_add_forward + remote_addr_x = strip(split(env['HTTP_X_FORWARDED_FOR'], ",")[-1]) + if remote_addr_x != '': + env['REMOTE_ADDR_X']=remote_addr_x + # If we're using a resolving logger, try to get the + # remote host from the resolver's cache. + if hasattr(server.logger, 'resolver'): + dns_cache=server.logger.resolver.cache + if dns_cache.has_key(env['REMOTE_ADDR_X']): + remote_host_x=dns_cache[env['REMOTE_ADDR_X']][2] + if remote_host_x is not None: + env['REMOTE_HOST_X']=remote_host_x + return env def continue_request(self, sin, request): *** Zope-2.4.1-src/ZServer/medusa/http_server.py Tue Jul 3 04:45:22 2001 --- zope-2.4.1/ZServer/medusa/http_server.py Tue Sep 25 12:29:08 2001 *************** *** 284,291 **** else: name = t[0] self.channel.server.logger.log ( ! self.channel.addr[0], ' - %s [%s] "%s" %d %d "%s" "%s"\n' % ( name, self.log_date_string (time.time()), --- 284,295 ---- else: name = t[0] + channel_addr=self.get_header('X-Forwarded-For') + if channel_addr: channel_addr = string.strip(string.split(channel_addr, ",")[-1]) + if not channel_addr: channel_addr = self.channel.addr[0] + self.channel.server.logger.log ( ! channel_addr, ' - %s [%s] "%s" %d %d "%s" "%s"\n' % ( name, self.log_date_string (time.time()), *** Zope-2.4.1-src/lib/python/AccessControl/User.py Sat Aug 4 22:49:26 2001 --- zope-2.4.1/lib/python/AccessControl/User.py Tue Sep 25 12:00:54 2001 *************** *** 1039,1048 **** if len(spec) == 1 and spec[0] == '*': return 1 ! if request.has_key('REMOTE_HOST'): host=request['REMOTE_HOST'] ! if request.has_key('REMOTE_ADDR'): addr=request['REMOTE_ADDR'] if not host and not addr: --- 1039,1052 ---- if len(spec) == 1 and spec[0] == '*': return 1 ! if request.has_key('REMOTE_HOST_X'): ! host=request['REMOTE_HOST_X'] ! elif request.has_key('REMOTE_HOST'): host=request['REMOTE_HOST'] ! if request.has_key('REMOTE_ADDR_X'): ! addr=request['REMOTE_ADDR_X'] ! elif request.has_key('REMOTE_ADDR'): addr=request['REMOTE_ADDR'] if not host and not addr:

1 0

removal of User Folders
by Jim Penny 24 Sep '01

24 Sep '01

Is there some function that is called when a User Folder is removed? If so, what is it? If not, is there a recommended way to delete users, any information stored about the User Folder's configuration, etc.? Thanks. Jim Penny

2 1

ZCatalog problem: sort_on bug
by Steve Alexander 24 Sep '01

24 Sep '01

I'm getting a strange problem with ZCatalog, using python 2.1, Zope from CVS. I get all the results I expect with this: <ul> <dtml-in "Catalog(process_step=['start','mailed'])"> <li> &dtml-subject_name; -- &dtml-relationship_name; -> &dtml-rater_name; </dtml-in> </ul> But, I only get one subject_name's worth of results with this: <ul> <dtml-in "Catalog(process_step=['start','mailed'], sort_on='subject_name')"> <li> &dtml-subject_name; -- &dtml-relationship_name; -> &dtml-rater_name; </dtml-in> </ul> This smells like a BTrees bug to me, but I'm not sure. I'm looking into this closely now, but if anyone's seen this before, please speak up! -- Steve Alexander Software Engineer Cat-Box limited

1 3

RE: [Zope-dev] Vulnerability: attacking can get file list and dir ectory
by sean.upton＠uniontrib.com 24 Sep '01

24 Sep '01

Personally, I think this really should be an integration issue instead of a Zope issue: use a front-end proxy server (i.e. Squid) and set up ACLs to prevent this... Sean -----Original Message----- From: Oliver Bleutgen [mailto:myzope@gmx.net] Sent: Monday, September 24, 2001 9:10 AM To: zope-dev(a)zope.org Subject: Re: [Zope-dev] Vulnerability: attacking can get file list and directory Hi shane, > Oliver Bleutgen wrote: >> From a non-technical, PR-wise point of view let me add that >> this type of "vulnerability" easily gets zope mentioned on lists >> like bugtraq. The perception is that these thing really are >> vulnerabilities. > You're right, a quick search on google for "path disclosure > vulnerability" yields a lot of hits for lots of applications. > It troubles me that people consider PDV to be important at all when the > client-side trojan bug is still fully exploitable on all browsers > including IE and Mozilla! (AFAIK) Client-side trojans, which can cause > your browser to invisibly post a comment on a weblog, execute a > financial transaction, or break into servers you maintain, are a major > risk. I had put something about that theme at the client-side trojan wiki, put I'll repeat myself since you mentioned it ... Methinks the creators of the http/1.1 rfc were aware of the dangers we call client-side trojan and wrote the following: " 9.1.1 Safe Methods Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others. In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them. " Zope really should not accept GET requests to dangerous manage_* (or other) methods, that would ensure it's at least compliant with the spirit of that rfc. If the user decides to use a browser which allows javascript to auto-submit forms and stuff, it's his choice. I have a feeling that other ideas like checking referer etc. are bound to fail after one or two generations of new browsers. We should have in mind that the same people who will design these browsers already had the bright idea of implementing auto-submitting of hidden forms. > PDV just yields information you might give out anyway. But maybe we > could deal with it anyway by writing an "error.log" instead of sending > the traceback to the browser. What do you think? I fear it would make working with zope harder for unexperienced users. When working with apache/perl on linux, I always had a tail -f /var/log/httpd/error.log running in a terminal, but if you're solely working on windows without using the power of cygwin or other tools, this might get tedious. What I would like to see is a error "product" which can be freely configured to show more or less details depending on its context (i.e. user/role etc.) and able to optionally write to a log file. I know this is a lot of work and has its technical problems, but it's a nice imagination. cheers, oliver _______________________________________________ Zope-Dev maillist - Zope-Dev(a)zope.org 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 )

2 1

Custom Login
by Ivan Raikov 24 Sep '01

24 Sep '01

Hello, Recently, I had to replace ZPublisher's default authentication scheme, as part of a product I'm working on. I am aware of the existence of LoginManager, exUserFolder, etc., but in this case I needed to have a custom login screen at root level, i.e. completely get rid of the basic HTTP authentication and browser popup window. So I replaced some of the HTTPRequest and HTTPResponse methods in order to present the user an HTML form whenever an 'Unauthorized' exception is raised. While I'm sure such an issue has arisen hundreds of times, somehow I was unable to find a product or a How-To that specifically addresses it, which means either I don't know how to browse the Web, or nobody has bothered to document their knowledge in the area. So I went ahead and created a simple Zope product that, upon installing, makes the necessary changes in HTTPRequest and HTTPResponse (HotFix style), so that cookie-based, HTML form login replaces the default one. For the curious, the product can be found at http://www.prism.gatech.edu/~gte085h/zope/CustomLogin/ In regards to this product, I've been pondering some questions that I'd like to be answered by knowledgeable people, if possible: 1. Is there a product that makes the changes I described, and where can I find it? 2. Does anyone think it's a good idea to provide some kind of a standardized API for replacing ZPublisher's authentication? 3. If a user attempts to access a resource, and is denied access, my modified HTTPResponse simply redirects to the login form, without bothering to record the URL the user originally tried to access (which can be a bad or a good thing, I suppose). Is there any way for an HTTPResponse instance to find out the URL of its HTTPRequest? 4. Not entirely related to this topic, but I noticed that the ChannelPipe class, used for communication between ZServer and ZPublisher, serves only one object instance at a time. What would be some practical difficulties in changing this class to serve multiple HTTPResponse instances? Finally, after noticing the ongoing discussion about the error HTML contents produced by ZPublisher upon an exception, I'd like to point out that it's extremely trivial to replace HTTPResponse._error_html and provide either custom behavior (e.g. sending email to the administrator), or custom HTML code, whether loaded from a file or hardcoded. Is anyone interested in me writing a How-To on this topic? The product I described above, already does that, so it would be rather easy for me to put together some documentation, provided that nobody has bothered to write any. Let me know... Sincerely, Ivan Raikov

2 1

RE: [Zope-dev] Vulnerability: attacking can get file list and dir ectory
by sean.upton＠uniontrib.com 24 Sep '01

24 Sep '01

On a high-traffic site, wouldn't the log get really big, really quickly with tracebacks? It is also nice to have the tracebacks in the browser window for debugging... Why not just enable tracebacks to clients from trusted IP address ranges or domains... Set this up as an option in Z2.py? Anyway, that's my 3-mile high take on it... Sean -----Original Message----- From: Shane Hathaway [mailto:shane@zope.com] Sent: Monday, September 24, 2001 7:59 AM To: Oliver Bleutgen Cc: zope-dev(a)zope.org Subject: Re: [Zope-dev] Vulnerability: attacking can get file list and directory Oliver Bleutgen wrote: > From a non-technical, PR-wise point of view let me add that > this type of "vulnerability" easily gets zope mentioned on lists > like bugtraq. The perception is that these thing really are > vulnerabilities. You're right, a quick search on google for "path disclosure vulnerability" yields a lot of hits for lots of applications. It troubles me that people consider PDV to be important at all when the client-side trojan bug is still fully exploitable on all browsers including IE and Mozilla! (AFAIK) Client-side trojans, which can cause your browser to invisibly post a comment on a weblog, execute a financial transaction, or break into servers you maintain, are a major risk. PDV just yields information you might give out anyway. But maybe we could deal with it anyway by writing an "error.log" instead of sending the traceback to the browser. What do you think? Shane _______________________________________________ Zope-Dev maillist - Zope-Dev(a)zope.org 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 )

3 2

Re: [Zope-dev] Vulnerability: attacking can get file list and directory
by Oliver Bleutgen 24 Sep '01

24 Sep '01

> On Sunday 23 September 2001 08:24 pm, Joachim Werner allegedly wrote: >> > Vulnerability: attacking can get file list and directory >> > Tested on Win32 platform >> > >> > Example: >> > telnet zopeserver 8080 >> > PROPFIND / HTTP/1.0 >> > <enter> >> > <enter> >> > <enter> >> > >> > < list files and directory > >> > >> > This tested on my site: >> > security.instock.ru 8080 >> >> This one really seems to be the old "WebDAV is not safe" one. I guess it >> has been tackled already. You should be able to switch the file listing >> off >> for the Anonymous User in Zope 2.4.1 ... >> >> Joachim > I totally agree. Tracebacks should not be visible to anonymous users! > Although I would hesitate to call this a vulnerability, it ranks up there > with the old ability to call objectIds by URL as anonymous. > The less information that anonymous users can glean about the server, the > better. From a non-technical, PR-wise point of view let me add that this type of "vulnerability" easily gets zope mentioned on lists like bugtraq. The perception is that these thing really are vulnerabilities. Proof: 17.9. A posting named "Yet another path disclosure vulnerability" targeted at oracle 9i appserver, and 21.9. "RM Security Advisory: Xcache Path Disclosure Vulnerability" both of which describe exactly the analogon to how zope handles things. cheers, oliver

7 7

Re: [Zope-dev] Vulnerability: attacking can get file list and directory
by Oliver Bleutgen 24 Sep '01

24 Sep '01

Hi shane, > Oliver Bleutgen wrote: >> From a non-technical, PR-wise point of view let me add that >> this type of "vulnerability" easily gets zope mentioned on lists >> like bugtraq. The perception is that these thing really are >> vulnerabilities. > You're right, a quick search on google for "path disclosure > vulnerability" yields a lot of hits for lots of applications. > It troubles me that people consider PDV to be important at all when the > client-side trojan bug is still fully exploitable on all browsers > including IE and Mozilla! (AFAIK) Client-side trojans, which can cause > your browser to invisibly post a comment on a weblog, execute a > financial transaction, or break into servers you maintain, are a major > risk. I had put something about that theme at the client-side trojan wiki, put I'll repeat myself since you mentioned it ... Methinks the creators of the http/1.1 rfc were aware of the dangers we call client-side trojan and wrote the following: " 9.1.1 Safe Methods Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others. In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them. " Zope really should not accept GET requests to dangerous manage_* (or other) methods, that would ensure it's at least compliant with the spirit of that rfc. If the user decides to use a browser which allows javascript to auto-submit forms and stuff, it's his choice. I have a feeling that other ideas like checking referer etc. are bound to fail after one or two generations of new browsers. We should have in mind that the same people who will design these browsers already had the bright idea of implementing auto-submitting of hidden forms. > PDV just yields information you might give out anyway. But maybe we > could deal with it anyway by writing an "error.log" instead of sending > the traceback to the browser. What do you think? I fear it would make working with zope harder for unexperienced users. When working with apache/perl on linux, I always had a tail -f /var/log/httpd/error.log running in a terminal, but if you're solely working on windows without using the power of cygwin or other tools, this might get tedious. What I would like to see is a error "product" which can be freely configured to show more or less details depending on its context (i.e. user/role etc.) and able to optionally write to a log file. I know this is a lot of work and has its technical problems, but it's a nice imagination. cheers, oliver

1 0

New: Cross Site Scripting vulnerability
by ALife 24 Sep '01

24 Sep '01

Example: http://www.zope.org/Documentation/<SCRIPT>alert(document.domain)</SCRIPT> http://www.zope.org/lalalalal<SCRIPT>alert(document.domain)</SCRIPT> http://www.zope.org/<SCRIPT>alert(document.cookie)</SCRIPT> For example, an attacker might post a message like Hello message board. This is a message. <SCRIPT>malicious code</SCRIPT> This is the end of my message. When a victim with scripts enabled in their browser reads this message, the malicious code may be executed unexpectedly. Scripting tags that can be embedded in this way include <SCRIPT>, <OBJECT>, <APPLET>, and <EMBED>.

6 6