On Fri, Jan 9, 2015 at 10:31 PM, Graham Dumpleton <grah...@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 <grah...@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 <grah...@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 <rpl...@apache.org> wrote: >>> >>>> >>>> >>>> On 01/09/2015 09:48 PM, Jeff Trawick wrote: >>>> > On Fri, Jan 9, 2015 at 3:23 PM, Joe Orton <jor...@redhat.com <mailto: >>>> jor...@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/
