In-Reply-To: <000b01c19c86$1f3c97e0$3bc283d9@ts> >Received: (qmail 17088 invoked from network); 14 Jan 2002 17:51:37 -0000 >Received: from outgoing2.securityfocus.com (HELO outgoing.securityfocus.com) (66.38.151.26) > by mail.securityfocus.com with SMTP; 14 Jan 2002 17:51:37 -0000 >Received: from lists.securityfocus.com (lists.securityfocus.com [66.38.151.19]) > by outgoing.securityfocus.com (Postfix) with QMQP > id 011858F2FE; Mon, 14 Jan 2002 09:59:27 -0700 (MST) >Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm >Precedence: bulk >List-Id: <bugtraq.list-id.securityfocus.com> >List-Post: <mailto:bugtraq@securityfocus.com> >List-Help: <mailto:bugtraq-help@securityfocus.com> >List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com> >List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com> >Delivered-To: mailing list bugtraq@securityfocus.com >Delivered-To: moderator for bugtraq@securityfocus.com >Received: (qmail 11602 invoked from network); 13 Jan 2002 23:05:57 -0000 >Message-ID: <000b01c19c86$1f3c97e0$3bc283d9@ts> >Repl Hi, I tried to figure out this issue, which was originally reported in the bugtraq mailing list http://www.securityfocus.com/archive/1/250126 a few days ago and found out the following: There's really a problem with Pi3Web 2.0 CGI handler for physical paths, which are exactly MAX_PATH (260) bytes long and end with illegal (series of) dot(s). The problem does exist due to a specific behaviour of the Windows API, which isn't handled correctly and will crash the server reproducible. - The problem is limited to Pi3Web 2.0 beta 1&2 on Win32. - Linux and Solaris versions aren't affected at all. - Older versions of Pi3Web aren't affected. - Configurations without CGI aren't affected. The problem could be reproduced by using the test case described in the original report. May be you've to vary the number of dots a bit (increase and/or decrease) dependant on the length of the physical path. A patch fixing the problem is available at sourceforge from now: http://sourceforge.net/tracker/index.php?func=detail&aid=505583&group_id=17753&ati d=317753 This .ZIP file contains 2 DLL's, which must be replaced in Pi3Web/bin. Don't forget to stop Pi3Web before you apply the patch and restart the server afterwards. A configuration based workaround is also possible by addition of the following line in object Scripts, e.g. in Pi3Web/Conf/Config.pi3: <Object> Name Scripts Class FlexibleHandlerClass Condition "&cmp(&dblookup(response,string,ObjectMap),Scripts)" # line added to check for script names ending on '.' CheckPath Condition="&regexp(*.,$z)" StatusCode StatusCode="404" ... Please report, if the problem could be reproduced before you applied the patch and if it was safely solved afterwards. -- regards Holger Zimmermann
