mod_proxy/2914: Segmentation fault on invalid server response

[Rick Ohnemus <ri...@ecompcon.com>]

>Number:         2914
>Category:       mod_proxy
>Synopsis:       Segmentation fault on invalid server response
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Thu Aug 27 07:10:01 PDT 1998
>Last-Modified:
>Originator:     rick@ecompcon.com
>Organization:
apache
>Release:        Apache/1.3.2-dev
>Environment:
BSD/OS pigasus.ecompcon.com 3.1 BSDI BSD/OS 3.1 i386 with all patches applied

gcc version 2.7.2.1
>Description:
The seg fault is being caused by ap_proxy_read_headers() returning NULL. The 
functions that call ap_proxy_read_headers() do not check for a NULL result.

I first noticed the problem in ap_proxy_http_handler(). It calls
ap_proxy_read_headers() then calls ap_table_mergen() and clear_connection()
using the retune value from ap_proxy_read_headers(). None of these functions
expect the response headers table to be NULL so they just dereference the
pointer causing a seg fault.

>How-To-Repeat:
visit www.idot.com using an apache proxy server.

The reponse I am seeing from www.idot.con is:
HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Date: Thu, 27 Aug 1998 13:28:50 GMT
HTTP/1.0 200 OK
Content-type: text/html

---- end of response ----
Notice the two HTTP status lines. The second one causes ap_proxy_read_headers()
to return NULL since the line does not contain a ':'.

>From reading the HTTP standards and draft standards, I get the impression that
this is an invalid response from their server. There should only be one HTTP
status line. This type of problem appears to be very common on servers running
Microsoft servers. Am I reading the standards correctly?

So, there are 2 problems here: 1) they are sending an invalid response (I'll
work on getting them to fix it); 2) apache is seg faulting (something no one
wants to happen).
>Fix:
1. Ignore the offending lines. This fits in with the old 'be liberal in what
you accept and strict in what you send' philosophy.

2. Send a nasty-gram back to the offending server.

3. ????
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, ]
[you need to include <ap...@Apache.Org> in the Cc line ]
[and leave the subject line UNCHANGED.  This is not done]
[automatically because of the potential for mail loops. ]
[If you do not include this Cc, your reply may be ig-   ]
[nored unless you are responding to an explicit request ]
[from a developer.                                      ]
[Reply only with text; DO NOT SEND ATTACHMENTS!         ]