You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Joe Orton <jo...@redhat.com> on 2015/01/09 21:23:13 UTC
CVE-2013-5704 fix breaks mod_wsgi
Since Jim is talking 2.4.11, I should report this now. We discovered
this week in Fedora: mod_wsgi does some interesting things in daemon
mode, notably that it allocates a request_rec internally which ends up
getting used by httpd.
Reason is, the fix for CVE-2013-5704 extends the request_rec:
http://svn.apache.org/r1619884
A mod_wsgi built against <= 2.4.10 will allocate a request_rec using the
old, smaller "wrong" size, and hence, if such a build is used with >=
2.4.11, it passes in the wrong-sized request_rec and that breaks later
when httpd tries to access r->trailers_*.
It's one of those fuzzy boundaries in the API, you can argue mod_wsgi is
wrong, but, I could argue it back; the struct *is* public, not got a
strong opinion on this personally.
Either way, the fix for CVE-2013-5704 ends up breaking backwards
compatibility with existing 2.4.x builds of mod_wsgi, which is kind of
Bad. I don't have a good proposal for how to fix or avoid this. Worst
case, we make clear the mod_wsgi case is API/ABI abuse and warn binary
distributors they have to handle this by rebuilding.
Regards, Joe
Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by Eric Covener <co...@gmail.com>.
On Mon, Jan 12, 2015 at 11:25 AM, Eric Covener <co...@gmail.com> wrote:
> Part of that question is probably "who else has figured out how to cope
ignore this trailing bit.
Re: Re: Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by Graham Dumpleton <gr...@apache.org>.
On 14 January 2015 at 09:10, <wr...@rowe-clan.net> wrote:
>
>
>
> --------- Original Message ---------
> Subject: Re: Re: CVE-2013-5704 fix breaks mod_wsgi
> From: "Graham Dumpleton" <gr...@apache.org>
> Date: 1/12/15 11:34 pm
> To: "dev@httpd.apache.org" <de...@httpd.apache.org>
>
> > But the damage has been done for some months on 2.2, and we are noticing
> this, now?
> All distros still shipping Apache 2.2 still are using older mod_wsgi 3.X
> versions
>
>
> Makes sense...
>
> which I don't at this point believe are affected by this issue.
>
> And why not?
>
> https://github.com/GrahamDumpleton/mod_wsgi/blob/stable/3.X/mod_wsgi.c
>
> /* Create and populate our own request object. */
> apr_pool_create(&p, c->pool);
> r = apr_pcalloc(p, sizeof(request_rec));
>
>
Because the code which is doing this is not running inside of the normal
Apache child worker processes but a separate managed process that mod_wsgi
creates just to run the WSGI application.
In that separate process things are much more controlled and arbitrary
Apache modules don't run stuff.
The only parts of the Apache code base that touch the new structure members
that I can find are the HTTP input filter, the proxy modules, sub requests
and logging.
In this separate managed processes the proxy modules are never use nor are
sub requests. The log functions which use the new structure members are
also not triggered as that only occurs in the Apache child worker processes.
The HTTP input filter is used, but due to the specific way that mod_wsgi
transfers data from the Apache child process to the separate managed
process, that request content is never chunked. As a consequence
the read_chunked_trailers() function which updates the structure members is
never called.
So although the request_rec size is going to be wrong, nothing ever
attempts to read or write past the short memory which is created in the
case of mod_wsgi <4.4.0 and so old versions aren't crashing when tested.
I agree this isn't ideal and users should update in case some other change
is made to Apache down the track which may change this, but right now it at
least means those older versions will not crash as mod_wsgi 4.4.0+ is.
FWIW, version 4.4.0 was only released November 28th 2014 and so not many
are actually likely using it.
Graham
Re: Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by Graham Dumpleton <gr...@apache.org>.
If interested, my initial blog post about the issue in relation to mod_wsgi
is now posted at:
* http://blog.dscpl.com.au/2015/01/important-modwsgi-information-about.html
The link to that has also been posted on the mod_wsgi mailing list and
Twitter.
Graham
On 13 January 2015 at 16:34, Graham Dumpleton <gr...@apache.org> wrote:
> > But the damage has been done for some months on 2.2, and we are noticing
> this, now?
>
> All distros still shipping Apache 2.2 still are using older mod_wsgi 3.X
> versions which I don't at this point believe are affected by this issue.
>
> People who build stuff from source code themselves would be using latest
> Apache 2.4.
>
> So the big hit on mod_wsgi will come with Apache 2.4.11.
>
> Graham
>
RE: Re: Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by wr...@rowe-clan.net.
--------- Original Message --------- Subject: Re: Re: CVE-2013-5704 fix breaks mod_wsgi
From: "Graham Dumpleton" <gr...@apache.org>
Date: 1/12/15 11:34 pm
To: "dev@httpd.apache.org" <de...@httpd.apache.org>
> But the damage has been done for some months on 2.2, and we are noticing this, now? All distros still shipping Apache 2.2 still are using older mod_wsgi 3.X versions
Makes sense...
which I don't at this point believe are affected by this issue.
And why not?
https://github.com/GrahamDumpleton/mod_wsgi/blob/stable/3.X/mod_wsgi.c
/* Create and populate our own request object. */
apr_pool_create(&p, c->pool); r = apr_pcalloc(p, sizeof(request_rec));
People who build stuff from source code themselves would be using latest Apache 2.4.
So the big hit on mod_wsgi will come with Apache 2.4.11.
From securityspace, 2.08% are already on 2.2.29, .51% are on 2.4.10 (of those who do not partially or completely truncate the server name).
I don't see any hit, since these are users who *can* and *do* build stuff themselves, and will have little to no difficulty updating mod_wsgi, as 2.2 users already needed to.
Re: Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by Graham Dumpleton <gr...@apache.org>.
> But the damage has been done for some months on 2.2, and we are noticing
this, now?
All distros still shipping Apache 2.2 still are using older mod_wsgi 3.X
versions which I don't at this point believe are affected by this issue.
People who build stuff from source code themselves would be using latest
Apache 2.4.
So the big hit on mod_wsgi will come with Apache 2.4.11.
Graham
RE: Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by wr...@rowe-clan.net.
--------- Original Message --------- Subject: Re: CVE-2013-5704 fix breaks mod_wsgi
From: "Joe Orton" <jo...@redhat.com>
Date: 1/12/15 11:05 am
To: dev@httpd.apache.org
On Mon, Jan 12, 2015 at 11:25:53AM -0500, Eric Covener wrote:
> On Fri, Jan 9, 2015 at 3:23 PM, Joe Orton <jo...@redhat.com> wrote:
> > Either way, the fix for CVE-2013-5704 ends up breaking backwards
> > compatibility with existing 2.4.x builds of mod_wsgi, which is kind of
> > Bad. I don't have a good proposal for how to fix or avoid this. Worst
> > case, we make clear the mod_wsgi case is API/ABI abuse and warn binary
> > distributors they have to handle this by rebuilding.
>
> Is there anything we can do in 2.4.11 for packagers who haven't picked
> this up yet since we're already picking up a problematic extension of
> the struct?
>
> What if we stashed away the MMN after these fields, and validated it?
> Or just a request_rec version?
It would be possible to do some hack. Say, stash something in r->notes
that this is a "real" request_rec, and check for that before accessing
r->trailers (which only happens in one place).
There may well be a cheaper way than modifying r->notes.
Not really useful, though.
You could extend ap_mpm_query easily enough but it doesn't win us anything in this version, or the 2.2 branch. We should be looking ahead at a more effective (although not more 'strict') ABI/API contract for 2.6/3.0.
But the damage has been done for some months on 2.2, and we are noticing this, now? I don't think there's anything to be done w.r.t. this issue in 2.4.11.
Once the module is compiled against the later MMN, there is no harm in initializing the extra fields, even if loaded against an earlier httpd core. But the MMN here is absolutely useless.
What we would have needed had we foreseen it and module authors adopted it... was a reversioning of each struct within httpd. I don't care that my loaded module knows of an earlier compatible conn_rec if the only thing it allocates is the request_req. The raw MMN value provides no insight.
Who is to say what is a 'real' request rec? No such beast if the module implements the request_rec entirely on its own.
Yes, mod_ftp, and mod_wsgi will have some pain from this enhancement. We eat it and move on, IMHO, and look forward to a new 2.x/3.0 world where we can introduce the semantics of incomplete types, versioned struct declarations and alloc/initializers where they are called for.
Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Jan 12, 2015 at 11:25:53AM -0500, Eric Covener wrote:
> On Fri, Jan 9, 2015 at 3:23 PM, Joe Orton <jo...@redhat.com> wrote:
> > Either way, the fix for CVE-2013-5704 ends up breaking backwards
> > compatibility with existing 2.4.x builds of mod_wsgi, which is kind of
> > Bad. I don't have a good proposal for how to fix or avoid this. Worst
> > case, we make clear the mod_wsgi case is API/ABI abuse and warn binary
> > distributors they have to handle this by rebuilding.
>
> Is there anything we can do in 2.4.11 for packagers who haven't picked
> this up yet since we're already picking up a problematic extension of
> the struct?
>
> What if we stashed away the MMN after these fields, and validated it?
> Or just a request_rec version?
It would be possible to do some hack. Say, stash something in r->notes
that this is a "real" request_rec, and check for that before accessing
r->trailers (which only happens in one place).
There may well be a cheaper way than modifying r->notes.
Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by Eric Covener <co...@gmail.com>.
On Fri, Jan 9, 2015 at 3:23 PM, Joe Orton <jo...@redhat.com> wrote:
> Either way, the fix for CVE-2013-5704 ends up breaking backwards
> compatibility with existing 2.4.x builds of mod_wsgi, which is kind of
> Bad. I don't have a good proposal for how to fix or avoid this. Worst
> case, we make clear the mod_wsgi case is API/ABI abuse and warn binary
> distributors they have to handle this by rebuilding.
Is there anything we can do in 2.4.11 for packagers who haven't picked
this up yet since we're already picking up a problematic extension of
the struct?
What if we stashed away the MMN after these fields, and validated it?
Or just a request_rec version?
That way we'd be be able to read past the end and blow up
intentionally w/ a message, but wouldn't be writing past the end and
blowing up much confusingly.
I think a big factor in whether we do something is how many modules
might have already been corrected for it. I am thinking not many if
we haven't heard about yet (other than mod_ftpd).
Part of that question is probably "who else has figured out how to cope
Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by Graham Dumpleton <gr...@apache.org>.
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
received.
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.
Graham
On 12 January 2015 at 23:20, Graham Dumpleton <gr...@apache.org> wrote:
> On 12 January 2015 at 22:27, Joe Orton <jo...@redhat.com> 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
>
>
>
Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by Graham Dumpleton <gr...@apache.org>.
On 12 January 2015 at 22:27, Joe Orton <jo...@redhat.com> 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
RE: Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by wr...@rowe-clan.net.
--------- Original Message --------- Subject: Re: CVE-2013-5704 fix breaks mod_wsgi
From: "Joe Orton" <jo...@redhat.com>
Date: 1/12/15 5:27 am
To: "Graham Dumpleton" <gr...@apache.org>
Cc: "dev@httpd.apache.org" <de...@httpd.apache.org>
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.)
Exactly. These fixes are already in for httpd's mod_ftp svn. I had also missed this while building that module and hadn't put it through its paces, as we were preparing 2.2.
The proper solution is to never let the module create a structure such as request_req. This would normally be accomplished by semi-opaque/incomplete data types, which weren't portably possible in '00 but might be realistic today.
Whether we expose a complete or incomplete datatype - that solution is to expose the object's allocator/initializer. OO programming topic 101.
Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by Joe Orton <jo...@redhat.com>.
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.)
Regards, Joe
Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, Jan 9, 2015 at 5:04 PM, Graham Dumpleton <gr...@apache.org> wrote:
> Thanks for the heads up and I appreciate very much the steps you are
> taking to limit possible affects.
>
> What I will do is the following:
>
> 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.
>
> 2. Publicise upcoming problem on my blog, mod_wsgi mailing list and doc
> sites and repo.
>
> 3. As a hack to try and ease the transition for anyone compiling from
> source code themselves, make a quick patch release of mod_wsgi which pads
> the size of request_rec when it is allocated, with at least 2 * size of a
> pointer. This way people can recompile this patched mod_wsgi now in advance
> and they shouldn't have an issue when the httpd binaries themselves are
> updated.
>
> 4. Work on more permanent solution. The possibility of API functions for
> creating the structures has been suggested but not ideal as it is catering
> for an obscure case where mod_wsgi may be the only transgressor. I have
> contemplated doing away with using the request_rec in the mod_wsgi daemon
> mode, but it was attractive for a few reasons. I will need to reassess how
> much I do need it and whether I can eliminate it and find other ways to do
> the things I was dependent on it for. One of the main things from memory
> was actually related to logging, so it may be possible to do away with it.
>
I can't speak specifically to more creators of request_rec, but there are
other cases (alternative mass vhost implementations come to mind, guiltily
I might add) where the only apparent solution is to build one of these key
structures.
>
> Thanks again for giving consideration for the problem I have caused.
>
> Graham
>
>
> On 10 January 2015 at 07:55, Ruediger Pluem <rp...@apache.org> wrote:
>
>>
>>
>> On 01/09/2015 09:48 PM, Jeff Trawick wrote:
>> > On Fri, Jan 9, 2015 at 3:23 PM, Joe Orton <jorton@redhat.com <mailto:
>> jorton@redhat.com>> wrote:
>> >
>> > Since Jim is talking 2.4.11, I should report this now. We
>> discovered
>> > this week in Fedora: mod_wsgi does some interesting things in daemon
>> > mode, notably that it allocates a request_rec internally which ends
>> up
>> > getting used by httpd.
>> >
>> > Reason is, the fix for CVE-2013-5704 extends the request_rec:
>> >
>> > http://svn.apache.org/r1619884
>> >
>> > A mod_wsgi built against <= 2.4.10 will allocate a request_rec
>> using the
>> > old, smaller "wrong" size, and hence, if such a build is used with
>> >=
>> > 2.4.11, it passes in the wrong-sized request_rec and that breaks
>> later
>> > when httpd tries to access r->trailers_*.
>> >
>> > It's one of those fuzzy boundaries in the API, you can argue
>> mod_wsgi is
>> > wrong, but, I could argue it back; the struct *is* public, not got a
>> > strong opinion on this personally.
>> >
>> > Either way, the fix for CVE-2013-5704 ends up breaking backwards
>> > compatibility with existing 2.4.x builds of mod_wsgi, which is kind
>> of
>> > Bad. I don't have a good proposal for how to fix or avoid this.
>> Worst
>> > case, we make clear the mod_wsgi case is API/ABI abuse and warn
>> binary
>> > distributors they have to handle this by rebuilding.
>> >
>> > Regards, Joe
>> >
>> >
>> > * One-time only: Make clear in announcement that mod_wsgi has to be
>> rebuilt.
>> > * Add helper functions to allocate a request_rec, conn_rec,
>> server_rec. It doesn't solve all possible problems of
>> > course but can drastically reduce the frequency of needing to recompile
>> a module that needs to do such things.
>> > * Module authors who allocate structures generally created by httpd own
>> the monitoring and announcement, or should just
>> > document "You must recompile this module every time you update httpd."
>> >
>>
>> +1
>>
>> Regards
>>
>> Rüdiger
>>
>>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, Jan 9, 2015 at 10:31 PM, Graham Dumpleton <gr...@apache.org>
wrote:
> Okay, I screwed up that analysis a bit. It is APR 1.X to 2.X which is the
> issue and I can fix by having:
>
> #if APR_MAJOR_VERSION < 2
> #include "apr_support.h"
> #endif
>
> The specific code was:
>
> #if APR_MAJOR_VERSION < 2
> rv = apr_wait_for_io_or_timeout(NULL, sock, 0);
> #else
> rv = apr_socket_wait(sock, APR_WAIT_WRITE);
> #endif
>
> Either way, a minor tweak to mod_wsgi code.
>
Not a bad thing thing; just note that a switch from apr 1-2 for general
users would only be done on a major httpd release boundary, so there would
be any number of other reasons for the module developer to test. (Devs and
a few other users testing one fix or another might experiment with apr 2 +
httpd from time to time and encounter this issue.)
>
> Graham
>
>
> On 10 January 2015 at 14:28, Graham Dumpleton <gr...@apache.org> wrote:
>
>> FWIW, there is potentially another issue for mod_wsgi coming up as well.
>> Seems that I was using an APR function which was tagged as internal and in
>> trunk of APR the header file that function is defined in is no longer
>> installed, or at least when within srclib of httpd, thus mod_wsgi will no
>> longer build against APR trunk. Luckily this function was only used in some
>> old dead code for Apache 1.3 and support for it has been dropped, so I can
>> remove the dependency. Will still require an update to mod_wsgi to ensure
>> that it can compile with latest APR. I am not sure if there is an intention
>> to update APR soon as well as httpd.
>>
>> Graham
>>
>> On 10 January 2015 at 09:04, Graham Dumpleton <gr...@apache.org> wrote:
>>
>>> Thanks for the heads up and I appreciate very much the steps you are
>>> taking to limit possible affects.
>>>
>>> What I will do is the following:
>>>
>>> 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.
>>>
>>> 2. Publicise upcoming problem on my blog, mod_wsgi mailing list and doc
>>> sites and repo.
>>>
>>> 3. As a hack to try and ease the transition for anyone compiling from
>>> source code themselves, make a quick patch release of mod_wsgi which pads
>>> the size of request_rec when it is allocated, with at least 2 * size of a
>>> pointer. This way people can recompile this patched mod_wsgi now in advance
>>> and they shouldn't have an issue when the httpd binaries themselves are
>>> updated.
>>>
>>> 4. Work on more permanent solution. The possibility of API functions for
>>> creating the structures has been suggested but not ideal as it is catering
>>> for an obscure case where mod_wsgi may be the only transgressor. I have
>>> contemplated doing away with using the request_rec in the mod_wsgi daemon
>>> mode, but it was attractive for a few reasons. I will need to reassess how
>>> much I do need it and whether I can eliminate it and find other ways to do
>>> the things I was dependent on it for. One of the main things from memory
>>> was actually related to logging, so it may be possible to do away with it.
>>>
>>> Thanks again for giving consideration for the problem I have caused.
>>>
>>> Graham
>>>
>>>
>>> On 10 January 2015 at 07:55, Ruediger Pluem <rp...@apache.org> wrote:
>>>
>>>>
>>>>
>>>> On 01/09/2015 09:48 PM, Jeff Trawick wrote:
>>>> > On Fri, Jan 9, 2015 at 3:23 PM, Joe Orton <jorton@redhat.com <mailto:
>>>> jorton@redhat.com>> wrote:
>>>> >
>>>> > Since Jim is talking 2.4.11, I should report this now. We
>>>> discovered
>>>> > this week in Fedora: mod_wsgi does some interesting things in
>>>> daemon
>>>> > mode, notably that it allocates a request_rec internally which
>>>> ends up
>>>> > getting used by httpd.
>>>> >
>>>> > Reason is, the fix for CVE-2013-5704 extends the request_rec:
>>>> >
>>>> > http://svn.apache.org/r1619884
>>>> >
>>>> > A mod_wsgi built against <= 2.4.10 will allocate a request_rec
>>>> using the
>>>> > old, smaller "wrong" size, and hence, if such a build is used
>>>> with >=
>>>> > 2.4.11, it passes in the wrong-sized request_rec and that breaks
>>>> later
>>>> > when httpd tries to access r->trailers_*.
>>>> >
>>>> > It's one of those fuzzy boundaries in the API, you can argue
>>>> mod_wsgi is
>>>> > wrong, but, I could argue it back; the struct *is* public, not
>>>> got a
>>>> > strong opinion on this personally.
>>>> >
>>>> > Either way, the fix for CVE-2013-5704 ends up breaking backwards
>>>> > compatibility with existing 2.4.x builds of mod_wsgi, which is
>>>> kind of
>>>> > Bad. I don't have a good proposal for how to fix or avoid this.
>>>> Worst
>>>> > case, we make clear the mod_wsgi case is API/ABI abuse and warn
>>>> binary
>>>> > distributors they have to handle this by rebuilding.
>>>> >
>>>> > Regards, Joe
>>>> >
>>>> >
>>>> > * One-time only: Make clear in announcement that mod_wsgi has to be
>>>> rebuilt.
>>>> > * Add helper functions to allocate a request_rec, conn_rec,
>>>> server_rec. It doesn't solve all possible problems of
>>>> > course but can drastically reduce the frequency of needing to
>>>> recompile a module that needs to do such things.
>>>> > * Module authors who allocate structures generally created by httpd
>>>> own the monitoring and announcement, or should just
>>>> > document "You must recompile this module every time you update httpd."
>>>> >
>>>>
>>>> +1
>>>>
>>>> Regards
>>>>
>>>> Rüdiger
>>>>
>>>>
>>>
>>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by Graham Dumpleton <gr...@apache.org>.
Okay, I screwed up that analysis a bit. It is APR 1.X to 2.X which is the
issue and I can fix by having:
#if APR_MAJOR_VERSION < 2
#include "apr_support.h"
#endif
The specific code was:
#if APR_MAJOR_VERSION < 2
rv = apr_wait_for_io_or_timeout(NULL, sock, 0);
#else
rv = apr_socket_wait(sock, APR_WAIT_WRITE);
#endif
Either way, a minor tweak to mod_wsgi code.
Graham
On 10 January 2015 at 14:28, Graham Dumpleton <gr...@apache.org> wrote:
> FWIW, there is potentially another issue for mod_wsgi coming up as well.
> Seems that I was using an APR function which was tagged as internal and in
> trunk of APR the header file that function is defined in is no longer
> installed, or at least when within srclib of httpd, thus mod_wsgi will no
> longer build against APR trunk. Luckily this function was only used in some
> old dead code for Apache 1.3 and support for it has been dropped, so I can
> remove the dependency. Will still require an update to mod_wsgi to ensure
> that it can compile with latest APR. I am not sure if there is an intention
> to update APR soon as well as httpd.
>
> Graham
>
> On 10 January 2015 at 09:04, Graham Dumpleton <gr...@apache.org> wrote:
>
>> Thanks for the heads up and I appreciate very much the steps you are
>> taking to limit possible affects.
>>
>> What I will do is the following:
>>
>> 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.
>>
>> 2. Publicise upcoming problem on my blog, mod_wsgi mailing list and doc
>> sites and repo.
>>
>> 3. As a hack to try and ease the transition for anyone compiling from
>> source code themselves, make a quick patch release of mod_wsgi which pads
>> the size of request_rec when it is allocated, with at least 2 * size of a
>> pointer. This way people can recompile this patched mod_wsgi now in advance
>> and they shouldn't have an issue when the httpd binaries themselves are
>> updated.
>>
>> 4. Work on more permanent solution. The possibility of API functions for
>> creating the structures has been suggested but not ideal as it is catering
>> for an obscure case where mod_wsgi may be the only transgressor. I have
>> contemplated doing away with using the request_rec in the mod_wsgi daemon
>> mode, but it was attractive for a few reasons. I will need to reassess how
>> much I do need it and whether I can eliminate it and find other ways to do
>> the things I was dependent on it for. One of the main things from memory
>> was actually related to logging, so it may be possible to do away with it.
>>
>> Thanks again for giving consideration for the problem I have caused.
>>
>> Graham
>>
>>
>> On 10 January 2015 at 07:55, Ruediger Pluem <rp...@apache.org> wrote:
>>
>>>
>>>
>>> On 01/09/2015 09:48 PM, Jeff Trawick wrote:
>>> > On Fri, Jan 9, 2015 at 3:23 PM, Joe Orton <jorton@redhat.com <mailto:
>>> jorton@redhat.com>> wrote:
>>> >
>>> > Since Jim is talking 2.4.11, I should report this now. We
>>> discovered
>>> > this week in Fedora: mod_wsgi does some interesting things in
>>> daemon
>>> > mode, notably that it allocates a request_rec internally which
>>> ends up
>>> > getting used by httpd.
>>> >
>>> > Reason is, the fix for CVE-2013-5704 extends the request_rec:
>>> >
>>> > http://svn.apache.org/r1619884
>>> >
>>> > A mod_wsgi built against <= 2.4.10 will allocate a request_rec
>>> using the
>>> > old, smaller "wrong" size, and hence, if such a build is used with
>>> >=
>>> > 2.4.11, it passes in the wrong-sized request_rec and that breaks
>>> later
>>> > when httpd tries to access r->trailers_*.
>>> >
>>> > It's one of those fuzzy boundaries in the API, you can argue
>>> mod_wsgi is
>>> > wrong, but, I could argue it back; the struct *is* public, not got
>>> a
>>> > strong opinion on this personally.
>>> >
>>> > Either way, the fix for CVE-2013-5704 ends up breaking backwards
>>> > compatibility with existing 2.4.x builds of mod_wsgi, which is
>>> kind of
>>> > Bad. I don't have a good proposal for how to fix or avoid this.
>>> Worst
>>> > case, we make clear the mod_wsgi case is API/ABI abuse and warn
>>> binary
>>> > distributors they have to handle this by rebuilding.
>>> >
>>> > Regards, Joe
>>> >
>>> >
>>> > * One-time only: Make clear in announcement that mod_wsgi has to be
>>> rebuilt.
>>> > * Add helper functions to allocate a request_rec, conn_rec,
>>> server_rec. It doesn't solve all possible problems of
>>> > course but can drastically reduce the frequency of needing to
>>> recompile a module that needs to do such things.
>>> > * Module authors who allocate structures generally created by httpd
>>> own the monitoring and announcement, or should just
>>> > document "You must recompile this module every time you update httpd."
>>> >
>>>
>>> +1
>>>
>>> Regards
>>>
>>> Rüdiger
>>>
>>>
>>
>
Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by Graham Dumpleton <gr...@apache.org>.
FWIW, there is potentially another issue for mod_wsgi coming up as well.
Seems that I was using an APR function which was tagged as internal and in
trunk of APR the header file that function is defined in is no longer
installed, or at least when within srclib of httpd, thus mod_wsgi will no
longer build against APR trunk. Luckily this function was only used in some
old dead code for Apache 1.3 and support for it has been dropped, so I can
remove the dependency. Will still require an update to mod_wsgi to ensure
that it can compile with latest APR. I am not sure if there is an intention
to update APR soon as well as httpd.
Graham
On 10 January 2015 at 09:04, Graham Dumpleton <gr...@apache.org> wrote:
> Thanks for the heads up and I appreciate very much the steps you are
> taking to limit possible affects.
>
> What I will do is the following:
>
> 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.
>
> 2. Publicise upcoming problem on my blog, mod_wsgi mailing list and doc
> sites and repo.
>
> 3. As a hack to try and ease the transition for anyone compiling from
> source code themselves, make a quick patch release of mod_wsgi which pads
> the size of request_rec when it is allocated, with at least 2 * size of a
> pointer. This way people can recompile this patched mod_wsgi now in advance
> and they shouldn't have an issue when the httpd binaries themselves are
> updated.
>
> 4. Work on more permanent solution. The possibility of API functions for
> creating the structures has been suggested but not ideal as it is catering
> for an obscure case where mod_wsgi may be the only transgressor. I have
> contemplated doing away with using the request_rec in the mod_wsgi daemon
> mode, but it was attractive for a few reasons. I will need to reassess how
> much I do need it and whether I can eliminate it and find other ways to do
> the things I was dependent on it for. One of the main things from memory
> was actually related to logging, so it may be possible to do away with it.
>
> Thanks again for giving consideration for the problem I have caused.
>
> Graham
>
>
> On 10 January 2015 at 07:55, Ruediger Pluem <rp...@apache.org> wrote:
>
>>
>>
>> On 01/09/2015 09:48 PM, Jeff Trawick wrote:
>> > On Fri, Jan 9, 2015 at 3:23 PM, Joe Orton <jorton@redhat.com <mailto:
>> jorton@redhat.com>> wrote:
>> >
>> > Since Jim is talking 2.4.11, I should report this now. We
>> discovered
>> > this week in Fedora: mod_wsgi does some interesting things in daemon
>> > mode, notably that it allocates a request_rec internally which ends
>> up
>> > getting used by httpd.
>> >
>> > Reason is, the fix for CVE-2013-5704 extends the request_rec:
>> >
>> > http://svn.apache.org/r1619884
>> >
>> > A mod_wsgi built against <= 2.4.10 will allocate a request_rec
>> using the
>> > old, smaller "wrong" size, and hence, if such a build is used with
>> >=
>> > 2.4.11, it passes in the wrong-sized request_rec and that breaks
>> later
>> > when httpd tries to access r->trailers_*.
>> >
>> > It's one of those fuzzy boundaries in the API, you can argue
>> mod_wsgi is
>> > wrong, but, I could argue it back; the struct *is* public, not got a
>> > strong opinion on this personally.
>> >
>> > Either way, the fix for CVE-2013-5704 ends up breaking backwards
>> > compatibility with existing 2.4.x builds of mod_wsgi, which is kind
>> of
>> > Bad. I don't have a good proposal for how to fix or avoid this.
>> Worst
>> > case, we make clear the mod_wsgi case is API/ABI abuse and warn
>> binary
>> > distributors they have to handle this by rebuilding.
>> >
>> > Regards, Joe
>> >
>> >
>> > * One-time only: Make clear in announcement that mod_wsgi has to be
>> rebuilt.
>> > * Add helper functions to allocate a request_rec, conn_rec,
>> server_rec. It doesn't solve all possible problems of
>> > course but can drastically reduce the frequency of needing to recompile
>> a module that needs to do such things.
>> > * Module authors who allocate structures generally created by httpd own
>> the monitoring and announcement, or should just
>> > document "You must recompile this module every time you update httpd."
>> >
>>
>> +1
>>
>> Regards
>>
>> Rüdiger
>>
>>
>
Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by Eric Covener <co...@gmail.com>.
mod_ftpd too I believe
Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by Graham Dumpleton <gr...@apache.org>.
Thanks for the heads up and I appreciate very much the steps you are taking
to limit possible affects.
What I will do is the following:
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.
2. Publicise upcoming problem on my blog, mod_wsgi mailing list and doc
sites and repo.
3. As a hack to try and ease the transition for anyone compiling from
source code themselves, make a quick patch release of mod_wsgi which pads
the size of request_rec when it is allocated, with at least 2 * size of a
pointer. This way people can recompile this patched mod_wsgi now in advance
and they shouldn't have an issue when the httpd binaries themselves are
updated.
4. Work on more permanent solution. The possibility of API functions for
creating the structures has been suggested but not ideal as it is catering
for an obscure case where mod_wsgi may be the only transgressor. I have
contemplated doing away with using the request_rec in the mod_wsgi daemon
mode, but it was attractive for a few reasons. I will need to reassess how
much I do need it and whether I can eliminate it and find other ways to do
the things I was dependent on it for. One of the main things from memory
was actually related to logging, so it may be possible to do away with it.
Thanks again for giving consideration for the problem I have caused.
Graham
On 10 January 2015 at 07:55, Ruediger Pluem <rp...@apache.org> wrote:
>
>
> On 01/09/2015 09:48 PM, Jeff Trawick wrote:
> > On Fri, Jan 9, 2015 at 3:23 PM, Joe Orton <jorton@redhat.com <mailto:
> jorton@redhat.com>> wrote:
> >
> > Since Jim is talking 2.4.11, I should report this now. We discovered
> > this week in Fedora: mod_wsgi does some interesting things in daemon
> > mode, notably that it allocates a request_rec internally which ends
> up
> > getting used by httpd.
> >
> > Reason is, the fix for CVE-2013-5704 extends the request_rec:
> >
> > http://svn.apache.org/r1619884
> >
> > A mod_wsgi built against <= 2.4.10 will allocate a request_rec using
> the
> > old, smaller "wrong" size, and hence, if such a build is used with >=
> > 2.4.11, it passes in the wrong-sized request_rec and that breaks
> later
> > when httpd tries to access r->trailers_*.
> >
> > It's one of those fuzzy boundaries in the API, you can argue
> mod_wsgi is
> > wrong, but, I could argue it back; the struct *is* public, not got a
> > strong opinion on this personally.
> >
> > Either way, the fix for CVE-2013-5704 ends up breaking backwards
> > compatibility with existing 2.4.x builds of mod_wsgi, which is kind
> of
> > Bad. I don't have a good proposal for how to fix or avoid this.
> Worst
> > case, we make clear the mod_wsgi case is API/ABI abuse and warn
> binary
> > distributors they have to handle this by rebuilding.
> >
> > Regards, Joe
> >
> >
> > * One-time only: Make clear in announcement that mod_wsgi has to be
> rebuilt.
> > * Add helper functions to allocate a request_rec, conn_rec, server_rec.
> It doesn't solve all possible problems of
> > course but can drastically reduce the frequency of needing to recompile
> a module that needs to do such things.
> > * Module authors who allocate structures generally created by httpd own
> the monitoring and announcement, or should just
> > document "You must recompile this module every time you update httpd."
> >
>
> +1
>
> Regards
>
> Rüdiger
>
>
Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by Ruediger Pluem <rp...@apache.org>.
On 01/09/2015 09:48 PM, Jeff Trawick wrote:
> On Fri, Jan 9, 2015 at 3:23 PM, Joe Orton <jorton@redhat.com <ma...@redhat.com>> wrote:
>
> Since Jim is talking 2.4.11, I should report this now. We discovered
> this week in Fedora: mod_wsgi does some interesting things in daemon
> mode, notably that it allocates a request_rec internally which ends up
> getting used by httpd.
>
> Reason is, the fix for CVE-2013-5704 extends the request_rec:
>
> http://svn.apache.org/r1619884
>
> A mod_wsgi built against <= 2.4.10 will allocate a request_rec using the
> old, smaller "wrong" size, and hence, if such a build is used with >=
> 2.4.11, it passes in the wrong-sized request_rec and that breaks later
> when httpd tries to access r->trailers_*.
>
> It's one of those fuzzy boundaries in the API, you can argue mod_wsgi is
> wrong, but, I could argue it back; the struct *is* public, not got a
> strong opinion on this personally.
>
> Either way, the fix for CVE-2013-5704 ends up breaking backwards
> compatibility with existing 2.4.x builds of mod_wsgi, which is kind of
> Bad. I don't have a good proposal for how to fix or avoid this. Worst
> case, we make clear the mod_wsgi case is API/ABI abuse and warn binary
> distributors they have to handle this by rebuilding.
>
> Regards, Joe
>
>
> * One-time only: Make clear in announcement that mod_wsgi has to be rebuilt.
> * Add helper functions to allocate a request_rec, conn_rec, server_rec. It doesn't solve all possible problems of
> course but can drastically reduce the frequency of needing to recompile a module that needs to do such things.
> * Module authors who allocate structures generally created by httpd own the monitoring and announcement, or should just
> document "You must recompile this module every time you update httpd."
>
+1
Regards
Rüdiger
Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by Joe Orton <jo...@redhat.com>.
On Sat, Jan 10, 2015 at 07:38:03AM -0500, Jeff Trawick wrote:
> On Fri, Jan 9, 2015 at 3:48 PM, Jeff Trawick <tr...@gmail.com> wrote:
> > * Add helper functions to allocate a request_rec, conn_rec, server_rec.
> > It doesn't solve all possible problems of course but can drastically reduce
> > the frequency of needing to recompile a module that needs to do such things.
>
> Actually, ap_{request_rec|conn_rec|server_rec}_size would be much better;
> that supports allocation, copy, as well as "Pfft! You better recompile me."
I think one of these solutions is probably necessary, but I'm not sure
which.
1) Only exporting the struct sizes means httpd cannot initialize the
structs, which is both a problem in general for extending structs and
specifically for this case (per my other mail).
2) Only exporting the struct sizes means we don't have to invent a new
API and decide what "initialize a request_rec (etc)" really means and
add new API/ABI guarantees there which we might screw up later.
3) We could have a stricter API rule which says "you can extend
request_rec (etc), but assume third-party modules might initialize the
the fields to zero." This kind of guarantee might be a tough
commitment.
It's definitely a "don't start from here" problem.
Regards, Joe
Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, Jan 9, 2015 at 3:48 PM, Jeff Trawick <tr...@gmail.com> wrote:
> On Fri, Jan 9, 2015 at 3:23 PM, Joe Orton <jo...@redhat.com> wrote:
>
>> Since Jim is talking 2.4.11, I should report this now. We discovered
>> this week in Fedora: mod_wsgi does some interesting things in daemon
>> mode, notably that it allocates a request_rec internally which ends up
>> getting used by httpd.
>>
>> Reason is, the fix for CVE-2013-5704 extends the request_rec:
>>
>> http://svn.apache.org/r1619884
>>
>> A mod_wsgi built against <= 2.4.10 will allocate a request_rec using the
>> old, smaller "wrong" size, and hence, if such a build is used with >=
>> 2.4.11, it passes in the wrong-sized request_rec and that breaks later
>> when httpd tries to access r->trailers_*.
>>
>> It's one of those fuzzy boundaries in the API, you can argue mod_wsgi is
>> wrong, but, I could argue it back; the struct *is* public, not got a
>> strong opinion on this personally.
>>
>> Either way, the fix for CVE-2013-5704 ends up breaking backwards
>> compatibility with existing 2.4.x builds of mod_wsgi, which is kind of
>> Bad. I don't have a good proposal for how to fix or avoid this. Worst
>> case, we make clear the mod_wsgi case is API/ABI abuse and warn binary
>> distributors they have to handle this by rebuilding.
>>
>> Regards, Joe
>>
>
> * One-time only: Make clear in announcement that mod_wsgi has to be
> rebuilt.
> * Add helper functions to allocate a request_rec, conn_rec, server_rec.
> It doesn't solve all possible problems of course but can drastically reduce
> the frequency of needing to recompile a module that needs to do such things.
>
Actually, ap_{request_rec|conn_rec|server_rec}_size would be much better;
that supports allocation, copy, as well as "Pfft! You better recompile me."
> * Module authors who allocate structures generally created by httpd own
> the monitoring and announcement, or should just document "You must
> recompile this module every time you update httpd."
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by Jim Jagielski <ji...@jaguNET.com>.
I'm ok with any of those, or all. Agreed that some sort
of allocator for req and conn_recs makes sense, esp as
we look to http2 and the idea of slave conn_recs
> On Jan 9, 2015, at 3:48 PM, Jeff Trawick <tr...@gmail.com> wrote:
>
> On Fri, Jan 9, 2015 at 3:23 PM, Joe Orton <jo...@redhat.com> wrote:
> Since Jim is talking 2.4.11, I should report this now. We discovered
> this week in Fedora: mod_wsgi does some interesting things in daemon
> mode, notably that it allocates a request_rec internally which ends up
> getting used by httpd.
>
> Reason is, the fix for CVE-2013-5704 extends the request_rec:
>
> http://svn.apache.org/r1619884
>
> A mod_wsgi built against <= 2.4.10 will allocate a request_rec using the
> old, smaller "wrong" size, and hence, if such a build is used with >=
> 2.4.11, it passes in the wrong-sized request_rec and that breaks later
> when httpd tries to access r->trailers_*.
>
> It's one of those fuzzy boundaries in the API, you can argue mod_wsgi is
> wrong, but, I could argue it back; the struct *is* public, not got a
> strong opinion on this personally.
>
> Either way, the fix for CVE-2013-5704 ends up breaking backwards
> compatibility with existing 2.4.x builds of mod_wsgi, which is kind of
> Bad. I don't have a good proposal for how to fix or avoid this. Worst
> case, we make clear the mod_wsgi case is API/ABI abuse and warn binary
> distributors they have to handle this by rebuilding.
>
> Regards, Joe
>
> * One-time only: Make clear in announcement that mod_wsgi has to be rebuilt.
> * Add helper functions to allocate a request_rec, conn_rec, server_rec. It doesn't solve all possible problems of course but can drastically reduce the frequency of needing to recompile a module that needs to do such things.
> * Module authors who allocate structures generally created by httpd own the monitoring and announcement, or should just document "You must recompile this module every time you update httpd."
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>
Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, Jan 9, 2015 at 3:23 PM, Joe Orton <jo...@redhat.com> wrote:
> Since Jim is talking 2.4.11, I should report this now. We discovered
> this week in Fedora: mod_wsgi does some interesting things in daemon
> mode, notably that it allocates a request_rec internally which ends up
> getting used by httpd.
>
> Reason is, the fix for CVE-2013-5704 extends the request_rec:
>
> http://svn.apache.org/r1619884
>
> A mod_wsgi built against <= 2.4.10 will allocate a request_rec using the
> old, smaller "wrong" size, and hence, if such a build is used with >=
> 2.4.11, it passes in the wrong-sized request_rec and that breaks later
> when httpd tries to access r->trailers_*.
>
> It's one of those fuzzy boundaries in the API, you can argue mod_wsgi is
> wrong, but, I could argue it back; the struct *is* public, not got a
> strong opinion on this personally.
>
> Either way, the fix for CVE-2013-5704 ends up breaking backwards
> compatibility with existing 2.4.x builds of mod_wsgi, which is kind of
> Bad. I don't have a good proposal for how to fix or avoid this. Worst
> case, we make clear the mod_wsgi case is API/ABI abuse and warn binary
> distributors they have to handle this by rebuilding.
>
> Regards, Joe
>
* One-time only: Make clear in announcement that mod_wsgi has to be rebuilt.
* Add helper functions to allocate a request_rec, conn_rec, server_rec. It
doesn't solve all possible problems of course but can drastically reduce
the frequency of needing to recompile a module that needs to do such things.
* Module authors who allocate structures generally created by httpd own the
monitoring and announcement, or should just document "You must recompile
this module every time you update httpd."
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: CVE-2013-5704 fix breaks mod_wsgi
Posted by Ruediger Pluem <rp...@apache.org>.
On 01/09/2015 09:23 PM, Joe Orton wrote:
> Since Jim is talking 2.4.11, I should report this now. We discovered
> this week in Fedora: mod_wsgi does some interesting things in daemon
> mode, notably that it allocates a request_rec internally which ends up
> getting used by httpd.
>
> Reason is, the fix for CVE-2013-5704 extends the request_rec:
>
> http://svn.apache.org/r1619884
>
> A mod_wsgi built against <= 2.4.10 will allocate a request_rec using the
> old, smaller "wrong" size, and hence, if such a build is used with >=
> 2.4.11, it passes in the wrong-sized request_rec and that breaks later
> when httpd tries to access r->trailers_*.
>
> It's one of those fuzzy boundaries in the API, you can argue mod_wsgi is
> wrong, but, I could argue it back; the struct *is* public, not got a
> strong opinion on this personally.
But our rules allow to extend public structs if new members are added to the end.
So if we say that mod_wsgi is right we would need to update our backporting rules.
If we say it is wrong, we may need to make it clearer that if public structs are
allocated directly via a module and handed back to any server functions this requires
possible recompilation of the module even for patch releases inside a stable branch.
>
> Either way, the fix for CVE-2013-5704 ends up breaking backwards
> compatibility with existing 2.4.x builds of mod_wsgi, which is kind of
> Bad. I don't have a good proposal for how to fix or avoid this. Worst
This is bad. Agreed.
> case, we make clear the mod_wsgi case is API/ABI abuse and warn binary
> distributors they have to handle this by rebuilding.
>
> Regards, Joe
>
Regards
Rüdiger