httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Dumpleton <>
Subject Re: CVE-2013-5704 fix breaks mod_wsgi
Date Mon, 12 Jan 2015 12:20:42 GMT
On 12 January 2015 at 22:27, Joe Orton <> wrote:

> On Sat, Jan 10, 2015 at 09:04:12AM +1100, Graham Dumpleton wrote:
> > 1. Verify that recompiling mod_wsgi is actually sufficient given than my
> > direct use of request_rec isn't going to populate the extra fields and
> they
> > will remain NULL still. As trailers shouldn't be expected in context the
> > request_rec is being used directly by mod_wsgi those attributes shouldn't
> > be touched, but if that is the case, why would it be crashing without
> > recompilation happening. So need to also actually verify whether it can't
> > limp on as is for now if it isn't crashing.
> Yup, I should have mentioned that too.  You are right, we had to pach
> mod_wsgi to fix the issue properly as well:
> that can/should be surrounded with
> #if AP_MODULE_MAGIC_AT_LEAST(20120211, 37)
> ...
> #endif
> make it conditional on an httpd with those fields.  (Hadn't
> submitted that back upstream yet sorry - we wanted to find a "proper"
> solution httpd-side for this.)

The problem I have is that Linux distros who are back porting the change
aren't going to be updating MODULE_MAGIC_NUMBER.

So if I add:

#if AP_MODULE_MAGIC_AT_LEAST(20120211, 37)
    r->trailers_in = apr_table_make(r->pool, 5);
    r->trailers_out = apr_table_make(r->pool, 5);

This only helps if someone is using Apache 2.4.11 or later where
MODULE_MAGIC_NUMBER has been updated.

Someone who takes the latest mod_wsgi code with the above change and
compiles it against an Apache with back ported change will still find that
mod_wsgi will crash as that code will never be compiled in.

In short, I can't see that I have any way of detecting that an Apache
instance which has back ported the change is being used at compile time.

The only hack I can think of, is that for where
AP_MODULE_MAGIC_AT_LEAST(20120211, 37) doesn't succeed, I try and calculate
whether the 'useragent_ip' member of the structure is still likely to be
the last thing that can fit in the amount of memory allocated for the
request_rec and if it isn't and the following memory is enough to hold the
trailers_in and trailers_out pointers, that i somehow work out where they
would fall and set them. This could be fiddly because of struct packing

I know it is asking a lot and likely too late, but what would have helped
immensely in such cases where back ports occur which change structure sizes
is that a #define was added within the struct where the new members were

    char *useragent_ip;

#define CVE_2013_5704 1

    /** MIME trailer environment from the request */
    apr_table_t *trailers_in;
    /** MIME trailer environment from the response */
    apr_table_t *trailers_out;

I know this goes against the MODULE_MAGIC_NUMBER idea, but the magic number
doesn't help with back ported changes like this.

With such #define's then I could have had:

#if AP_MODULE_MAGIC_AT_LEAST(20120211, 37) || defined(CVE_2013_5704)
    r->trailers_in = apr_table_make(r->pool, 5);
    r->trailers_out = apr_table_make(r->pool, 5);

So right now it looks like I have to use the rather fragile approach of
trying to work out whether the size of request_rec is no larger without
actually being able to access the members, which if they didn't exist would
cause a compile time failure.


View raw message