httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 48359] New: Buffer overflow related to setting RequestHeader
Date Wed, 09 Dec 2009 15:21:44 GMT

           Summary: Buffer overflow related to setting RequestHeader
           Product: Apache httpd-2
           Version: 2.2.9
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P2
         Component: Core

The background is that we use mod_headers to set request headers like this :
RequestHeader set X-MS-Unique-Id %{UNIQUE_ID}e env=!HAVE_X-MS-Unique-Id

[ the env=! part does not matter -- it does it even for statically configured
request headers ]

This works fine when Apache directly serves a request first time. It breaks
badly when Apache uses a subrequest during its processing. This is because
mod_headers sets the header (in r->headers_in) during the subrequest, using the
request pool from that subrequest.

Unfortunately, Apache passes subrequests a reference to r->headers_in, not a
copy. So at the end of the subrequest when the sub-request's pool is destroyed,
you have invalid data on the parent request's headers_in table.

The core apache code responsible for this is ap_set_sub_req_protocol() in
server/protocol.c :

/* did the original request have a body? (e.g. POST w/SSI tags)
* if so, make sure the subrequest doesn't inherit body headers
if (apr_table_get(r->headers_in, "Content-Length")
|| apr_table_get(r->headers_in, "Transfer-Encoding")) {
clone_headers_no_body(rnew, r);
} else {
/* no body (common case). clone headers the cheap way */
rnew->headers_in = r->headers_in;

Unfortunately, the 'cheap way' allows subrequests to modify the parent
request's data structures. We fixed the problem by changing this to :

else {
/* no body (common case). clone headers the cheap way */
/* rnew->headers_in = r->headers_in; */
rnew->headers_in = apr_table_copy(rnew->pool, r->headers_in);

There is a performance penalty with this. One other solution would be to modify
mod_headers to set the table value using the table's own pool rather than its
request pool, but that doesn't prevent subrequests can having potentially
strange side-effects.

This bug has potentially serious security consequences as the main request ends
up referencing memory it shouldn't be doing. We have seen it give away security
sensitive data to the client, and would like to see this patched and a security
fix made available as soon as possible please.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message