Re: [Zope-dev] Re: [Zope] isecure XML-RPC handling.
Rossen Raykov writes: * the immediate correspondence between the request and the response containing essential information to analyse the problem It's application problem and the application have to handle it. Log all the request/responses on the server or the client side. It's a standard problem, I wish the framework provides a solution (as it did up to now). * newbies They have nothing to do in a production environment don't they? I speak about debug mode! It may or may not have something to do in production environment. Even with the stack trace immediately in the response, they report problems with no or missing essential details about the problem. Then how one can help there? We try our best. One of the most essential features is an immediate feedback upon problems with easy access to the information that may help to analyse the problem. ... The point is that production differ from development environment. In the development environment on can do whatever he needs. In a production environment reporting information as physical path on the server, internal network addresses etc. is unexceptable. I am with you to say that in non-debug mode, such information should not be exposed. However, I think that debug mode can even in a production environment be necessary under some circumstances. I do not need internal port information, network addresses of absolute path, but I may need other (more sensible) information about the problem. The conclusion is make the server not to dump the stack in the response if -D option does not imply. Okay! With -D dump the processor registers if you would like ;) I won't ;-), it's not the adequate abstraction level. Dieter ___ 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] Re: [Zope] isecure XML-RPC handling.
* the immediate correspondence between the request and the response containing essential information to analyse the problem It's application problem and the application have to handle it. Log all the request/responses on the server or the client side. * newbies They have nothing to do in a production environment don't they? Even with the stack trace immediately in the response, they report problems with no or missing essential details about the problem. Then how one can help there? This will become worse when the error information is hidden in a log. The point is that production differ from development environment. In the development environment on can do whatever he needs. In a production environment reporting information as physical path on the server, internal network addresses etc. is unexceptable. Look at it from a different prospective: Someone is browsing Internet and a site is responding like: Microsoft OLE DB Provider for ODBC Drivers error '80040e14' [Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near the keyword 'or'. /login.asp, line 11 Couple scenarios: 1. If he is a regular user he will go to the next site and most probably will never come back to that site again. 2. If he is tester or developer - oops the code have problem we have to fix it. 3. If he is intruder then Bingo! the site have problems escaping special characters before to pass them to the SQL server! Let's have a party! The situation with Zope is similar. Shall the dump help the regular surfer? I doubt so. Shall it benefit the developer or the tester? Most probably not since they are not performing their activities on the production site. Shall it benefit third parity developers that are requesting services from you site? May be particular, since they can report the stack to you, but you may get that information from you log any way. Since they can not control the code on you side this will not make their live easier.. The only left is the intruder! The conclusion is make the server not to dump the stack in the response if -D option does not imply. With -D dump the processor registers if you would like ;) People have to be able to control this and if there is more precise control like debug level - then it is even better. BW if a program is expecting XML-RPC response but it is receiving stack trace it may be a little confusing (especially for a not so well written program ;). Zope first have to conform the protocol for XML-RPC exchange (return XML response) and after that to sweet the developers (dump error in the server's log). Okay! Dieter Regards, Rossen _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.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] Re: [Zope] isecure XML-RPC handling.
From: Rossen Raykov [EMAIL PROTECTED] Shall the dump help the regular surfer? I doubt so. Shall it benefit the developer or the tester? Most probably not since they are not performing their activities on the production site. Oh, they most definitely help the developer or tester, because errors do appear on production sites too, and it can be very hard to recreate the problem. BUT: The developer has access to the system, and the dump doesn't have to be included in the HTML output. Maybe error dumps could be sent to a disk-log of some sort? ___ 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] Re: [Zope] isecure XML-RPC handling.
Shall the dump help the regular surfer? I doubt so. Shall it benefit the developer or the tester? Most probably not since they are not performing their activities on the production site. Oh, they most definitely help the developer or tester, because errors do appear on production sites too, and it can be very hard to recreate the problem. The only one problem there is that if a surfer sees the dump most probably he will not send it to the developer BUT: The developer has access to the system, and the dump doesn't have to be included in the HTML output. Maybe error dumps could be sent to a disk-log of some sort? Exactly that's my point. Log it with as many details as you can! Log it on the local file system or use syslog or a database but do not send it to the users browser. Do not put it in the response if the server is running without -D option. Regards, Rossen _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.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] Re: [Zope] isecure XML-RPC handling.
On Sat, 6 Apr 2002, Rossen Raykov wrote: BUT: The developer has access to the system, and the dump doesn't have to be included in the HTML output. Maybe error dumps could be sent to a disk-log of some sort? Exactly that's my point. Log it with as many details as you can! From what he says, Shane's new better tracebacks code, which I believe will be in 2.6, does the equivalent of this. --RDM ___ 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] Re: [Zope] isecure XML-RPC handling.
Rossen Raykov writes: ... 1. the server log 2. the output to the client. ... In the second case it is better if Zope is returning just the error or the response. In the XML-RPC case the error have to be a valid XML-RPC response, not a stack trace. Thus, this may mean an exception with an XML-quoted stack trace. I can get that a stack trace may be extremely useful for a developer but cant he see the server's error log? There are two reasons, I prefer the stack trace in the response: * the immediate correspondence between the request and the response containing essential information to analyse the problem * newbies Even with the stack trace immediately in the response, they report problems with no or missing essential details about the problem. This will become worse when the error information is hidden in a log. BW if a program is expecting XML-RPC response but it is receiving stack trace it may be a little confusing (especially for a not so well written program ;). Zope first have to conform the protocol for XML-RPC exchange (return XML response) and after that to sweet the developers (dump error in the server's log). Okay! Dieter ___ 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] Re: [Zope] isecure XML-RPC handling.
Rossen Raykov wrote: My point was that Zope is revealing internal information that is believed to be private and invisible for the Internet users. It happens in its default (debug) installation and even after -D option is removed from the startup script. Rossen and others interested in tracebacks, If you can, please check out the latest Zope from CVS. Tracebacks no longer appear by default, and even when they do, they do not show any filesystem paths. (If you already have a checkout, make sure you use cvs up -dP to get the new product.) To see tracebacks, add a Site Error Log to your Zope. After an exception has occurred, visit it (it's called error_log). It will let you see the site errors that have occurred recently. 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-dev] Re: [Zope] isecure XML-RPC handling.
Shane Hathaway writes: If you can, please check out the latest Zope from CVS. Tracebacks no longer appear by default, and even when they do, they do not show any filesystem paths. (If you already have a checkout, make sure you use cvs up -dP to get the new product.) I am very interested in filesystem paths, not necessary absolute ones but relative pathnames are very helpful to locate a problem. Dieter ___ 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] Re: [Zope] isecure XML-RPC handling.
There are two completely different things: 1. the server log 2. the output to the client. In the first case you may log everything that you thing it is reasonable - stack traces and dumps, relative and absolute paths, etc. It can may be assumed that is secure since in general it is not accessible out of the box. My personal opinion is that even this log have to differ if -D (debug option) is misplayed. In the second case it is better if Zope is returning just the error or the response. In the XML-RPC case the error have to be a valid XML-RPC response, not a stack trace. I can get that a stack trace may be extremely useful for a developer but cant he see the server's error log? BW if a program is expecting XML-RPC response but it is receiving stack trace it may be a little confusing (especially for a not so well written program ;). Zope first have to conform the protocol for XML-RPC exchange (return XML response) and after that to sweet the developers (dump error in the server's log). Regards, Rossen - Original Message - From: Dieter Maurer [EMAIL PROTECTED] To: Shane Hathaway [EMAIL PROTECTED] Cc: Rossen Raykov [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, April 04, 2002 2:55 PM Subject: Re: [Zope-dev] Re: [Zope] isecure XML-RPC handling. Shane Hathaway writes: If you can, please check out the latest Zope from CVS. Tracebacks no longer appear by default, and even when they do, they do not show any filesystem paths. (If you already have a checkout, make sure you use cvs up -dP to get the new product.) I am very interested in filesystem paths, not necessary absolute ones but relative pathnames are very helpful to locate a problem. Dieter _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.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] Re: [Zope] isecure XML-RPC handling.
I think most people missed the point here. I don't think Rossen is asking for help on running zope or getting xml-rpc to work with it. He's observed a security problem: he believes the fact that a traceback including path names is included in the error response is a security exposure. This has been discussed on zope-dev before, but the fact remains that the security community *does* treat exposure of filesystem path information as a security issue. Right. There is already code for Zope 2.6 and Zope 3 that addresses this. Shane's new traceback formatting makes the trace information far more readable in addition to removing filesystem path information. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation 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] Re: [Zope] isecure XML-RPC handling.
Hi all, My point was that Zope is revealing internal information that is believed to be private and invisible for the Internet users. It happens in its default (debug) installation and even after -D option is removed from the startup script. I try some XML-RPC requests against www.zope.org (2.3.2) and against the default 2.5.0 installation for Windows (with and without -D option). In both cases Zope was reviling the physical location of the distribution. In the case of www.zope.org it was reviling even information about it's internal network (this may be also possible in 2.5.0 but I do not have the time to create complicated enough configuration). In general Zope have not to reveal any physical information neither about it's installation nor about the internal network behind it. If you need to print traces - use relative paths to the server root. If the debug option is omitted - just print the error and do not print any stack dumps at all! People have to be aware that the default installation is in debug mode and the results of that. I believe many people will be surprised to learn that they are exposing information about their private networks and server setups. Finally two clarifications: 1. Zope 2.3.2 do support XML-RPC. Try example one against www.zope.org it will work just fine! 2. Zope Zope 2.5.0 in it's default installation (debug mode) still is revealing information about the physical location of the installed server. See the dump in example two. It is produced as a result of the XML-RPC example from my first e-mail. Regards, Rossen Example one --- POST /Foo/Bar/MyFolder HTTP/1.0 Content-Type: text/xml Content-length: 110 ?xml version='1.0'? methodCall methodNametitle_or_id/methodName params /params /methodCall Example two --- ... Bobo-Exception-File: C:\PROGRA~1\WebSite\bin\lib\xmllib.py ... Traceback (innermost last): File C:\PROGRA~1\WebSite\lib\python\ZPublisher\Publish.py, line 150, in publish_module File C:\PROGRA~1\WebSite\lib\python\ZPublisher\Publish.py, line 114, in publish File C:\PROGRA~1\WebSite\lib\python\Zope\__init__.py, line 158, in zpublisher_exception_hook (Object: Zope) File C:\PROGRA~1\WebSite\lib\python\ZPublisher\Publish.py, line 63, in publish File C:\PROGRA~1\WebSite\lib\python\ZPublisher\HTTPRequest.py, line 357, in processInputs File C:\PROGRA~1\WebSite\lib\python\ZPublisher\xmlrpc.py, line 47, in parse_input File C:\PROGRA~1\WebSite\lib\python\xmlrpclib.py, line 531, in loads File C:\PROGRA~1\WebSite\bin\lib\xmllib.py, line 172, in close File C:\PROGRA~1\WebSite\bin\lib\xmllib.py, line 405, in goahead File C:\PROGRA~1\WebSite\bin\lib\xmllib.py, line 794, in syntax_error Error: (see above) - Original Message - From: Brian Lloyd [EMAIL PROTECTED] To: R. David Murray [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Rossen Raykov [EMAIL PROTECTED] Sent: Wednesday, April 03, 2002 12:20 PM Subject: RE: [Zope-dev] Re: [Zope] isecure XML-RPC handling. I think most people missed the point here. I don't think Rossen is asking for help on running zope or getting xml-rpc to work with it. He's observed a security problem: he believes the fact that a traceback including path names is included in the error response is a security exposure. This has been discussed on zope-dev before, but the fact remains that the security community *does* treat exposure of filesystem path information as a security issue. Right. There is already code for Zope 2.6 and Zope 3 that addresses this. Shane's new traceback formatting makes the trace information far more readable in addition to removing filesystem path information. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.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] Re: [Zope] isecure XML-RPC handling.
On Tue, Apr 02, 2002 at 04:01:41PM -0500, Eron Lloyd wrote: On that thought, I'd like to see Zope.org become much more modern, and reflect the *latest* and *greatest* functionality of Zope. Deprecation of the hybrid PTK that's used, as well as updating and polishing of the site regularly. In fact, I'd like to see more of a portal feel to it, that's both personalized and customized to my needs. For instance, log into my account, download 2.5.1b1, come back a week later and here's a big notice that beta2 is available for *my* setup. Also, can we see some Web services? Imagine, in the management interface, and visiting the Control Panel. There is an Update tab, which when loaded queries zope.org with the XML-RPC method zope.webservices.getUpdates(my_install), which passes in my server's version, installed products, etc. and lists updates, hotfixes, and other notices. With the flexibility and dynamic runtime nature of Python, i wonder how hard it would be to update a running server. Head over to [EMAIL PROTECTED] and help out then; the effort to build a new zope.org is already well under way. -- 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 )
