httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 37244] New: - Apache 1.3.33 : binary characters in HTTP header - buffer overflow during HTTP transactions??
Date Tue, 25 Oct 2005 23:27:49 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=37244>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37244

           Summary: Apache 1.3.33 : binary characters in HTTP header -
                    buffer overflow during HTTP transactions??
           Product: Apache httpd-1.3
           Version: HEAD
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: Other
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: roshan.cheereth@wipro.com


Hi, 


  We had recently migrated from Apache 1.3.28 (HP-UX) to Apache 1.3.33 
(Linux) and are facing a wierd senario where in we have got bad request 
responses in the logs at some important pages in the website. 


What was triaged till now: 
---------------------------- 
 TCP dump was taken and studied: what I found was at the end of a HTTP 
post request coming from the client ends with 5 binary characters (this 
number varies) which are more than the "Content-Length" specified in 
the header. Now the webserver forwards this data specified within the 
content length and a response is sent back as expected. The next 
request which comes in from the client gets the 5 extra binary 
characters prepended to the GET request and this causes a HTTP 400 
response. These 5 binary characters show up in the access logs of 
apache along with the above mentioned GET request and hex values are 
the same. 

A sample selection as seen in the access logs (Note the binary values before 
the GETs):
==============================================================================
160.81.118.42 - - [17/Oct/2005:01:21:37 -0500] "GET /docroot/controlpage.jsp?
id=pcat17014&type=page&_requestid=120816 HTTP/1.1" 200 
58532 "https://secure.somesite.com/docroot/controlpage.jsp?
id=pcat17013&type=page&_requestid=120813" "Mozilla/4.0 (compatible; MSIE 6.0; 
GomezAgent 2.0; Windows NT)"
67.84.19.77 - - [17/Oct/2005:01:22:58 -0500] "\xe9\xc1
\xbf\x8djGET /docroot/controlpage.jsp?id=pcat17014&type=page&_requestid=117467 
HTTP/1.1" 200 63330 "https://secure.somesite.com/docroot/controlpage.jsp?
id=pcat17013&type=page&_requestid=117417" "Mozilla/4.0 (compatible; MSIE 6.0; 
AOL 9.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
69.168.182.91 - - [17/Oct/2005:01:23:18 -0500] "\xf3\xaf\x86\xc7
\xc7GET /docroot/controlpage.jsp?id=pcat17014&type=page&_requestid=121650 
HTTP/1.1" 200 62035 "https://secure.somesite.com/docroot/controlpage.jsp?
id=pcat17013&type=page&_requestid=121604" "Mozilla/4.0 (compatible; MSIE 6.0; 
Windows NT 5.1; .NET CLR 1.1.4322)"
172.175.206.213 - - [17/Oct/2005:01:23:48 -0500] "\xe3,\xc5
\x9c\xafX\x85K,\xe3@\x97\x9eU`FGET /docroot/controlpage.jsp?
id=pcat17014&type=page&_requestid=127093 HTTP/1.1" 200 
61442 "https://secure.somesite.com/docroot/controlpage.jsp?
id=pcat17013&type=page&_requestid=126893" "Mozilla/4.0 (compatible; MSIE 6.0; 
AOL 9.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
71.107.55.61 - - [17/Oct/2005:01:28:14 -0500] "GET /docroot/controlpage.jsp?
id=pcat17014&type=page&_requestid=117849 HTTP/1.1" 200 
58626 "https://secure.somesite.com/docroot/controlpage.jsp?
id=pcat17013&type=page&_requestid=117829" "Mozilla/4.0 (compatible; MSIE 6.0; 
Windows NT 5.1; SV1)"
198.22.123.105 - - [17/Oct/2005:01:31:36 -0500] "GET /docroot/controlpage.jsp?
id=pcat17014&type=page&_requestid=121593 HTTP/1.0" 200 
59148 "https://secure.somesite.com/docroot/controlpage.jsp?
id=pcat17013&type=page&_requestid=121588" "Mozilla/4.0 (compatible; MSIE 6.0; 
Windows NT 5.0; .NET CLR 1.1.4322)"
===================================================================

This behaviour is seen quite frequently in all the new (linux) webservers and 
was not observed with the earlier Apache 1.3.28 (HP-UX). 


Questions: 
------------ 
1. Just to confirm, is a CRLF expected after the post request? The 
request had a content-length of 3025 and was sent to the webserver in 
chunks of 1460, 1460 and 110 which totals to 3030 including the extra 5 
bytes. Also would the CRLF be included in the 3025 bytes mentioned in 
the content-length? 


2. Where do these binary values get appended to the POST request from 
the client? Is it a bug, some kind of buffer overflow? Is it a spyware in the 
client? or is it a possible spoofing effort? 


3. What are the obivious or possible impacts of this observed behaviour? 


4. Is there any solution for this from a configuration standpoing with 
Apache 1.3.33 or will reverting back to Apache 1.3.28 on Linux help? 


5. Where do you think I should post this data to get quick resolution? 


Thanks in advance, 
Roshan

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message