DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27352>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27352 Wrong handling of IPs in decimal representation and/or numeric hostnames Summary: Wrong handling of IPs in decimal representation and/or numeric hostnames Product: Apache httpd-2.0 Version: 2.0.48 Platform: PC URL: http://3522028483/ OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Core AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] Let's assume we have a request to http://httpd.apache.org/ Now let's convert httpd.apache.org to other representations: httpd.apache.org = 209.237.227.195 209.237.227.195 = 0xd1ede3c3 0xd1ede3c3 = 3522028483 So from the browser's point of view all the following is identical: http://httpd.apache.org/ http://209.237.227.195/ http://3522028483/ The latter is where fix_hostname() in server/vhost.c misbehaves. It calls apr_parse_addr_port() to split host and port number. apr_parse_addr_port() itself decides as the host is a pure number that it must be a port number which is then naturally illegal as it is greater than 65535. As apr_parse_addr_port() now returns an error fix_hostname() fails and returns HTTP_BAD_REQUEST. There are two ways to fix this. Either treat the number as a hostname which will cause differing views between browser and server or use such a number as an IP if it is within a valid IP range. The latter should be preferred but it has security implications as long as the decimal number is not converted back into standard dotted notation. These implications are simply that nearly all configurations detect IPs only in the dotted notation and there will be lots of side effects if e.g. scripts would get the decimal IP representation instead of the dotted one. And for security considerations think especially of the implications for mod_proxy. A side effect of this misbehaviour seems to be that the ErrorDocument directive doesn't work in this case. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
