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:44:03 GMT
BTW. I need to go back and check, but I actually suspect that the crash
will only occur in mod_wsgi where mod_wsgi 4.4.0 or later was being used.
It was only in 4.4.0 that content started to be passed between the Apache
child worker processes and the mod_wsgi daemon process using chunking.

The WSGI specification doesn't actually permit chunked request content or
the idea of Apache input filters that can change the length of the request
content but not change the content length.

I did have a WSGIChunkedRequests directive to allow you to side step the
WSGI specification and allow your application to work with these, but it
was broken for mod_wsgi daemon mode and only worked for embedded mode. The
change in 4.4.0 fixed that and at the same time had to start using chunking
so could detect when request content had been truncated before all being

If this turns out to be the case, that may limit damage a big, as most
distros are still on ancient mod_wsgi versions and not using mod_wsgi 4.X
versions at all. They wouldn't therefore need to patch the older versions I
don't think, nor even possibly recompile them.

I will do some checking with older versions tomorrow, as well as work on
the hack that tries to infer the request_rec size to work out if the CVE
change has been back ported.


On 12 January 2015 at 23:20, Graham Dumpleton <> wrote:

> 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);
> #endif
> 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
> issues.
> 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
> added.
>     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);
> #endif
> 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.
> Graham

View raw message