httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Dumpleton <grah...@apache.org>
Subject Re: CVE-2013-5704 fix breaks mod_wsgi
Date Fri, 09 Jan 2015 22:04:12 GMT
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 <rpluem@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
>
>

Mime
View raw message