On 12 January 2015 at 22:27, Joe Orton <[email protected]> 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:
>
>
> http://pkgs.fedoraproject.org/cgit/mod_wsgi.git/plain/mod_wsgi-4.4.3-trailers.patch?h=f21
>
> that can/should be surrounded with
>
> #if AP_MODULE_MAGIC_AT_LEAST(20120211, 37)
> ...
> #endif
>
> ...to 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
