Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 995B710773 for ; Sat, 10 Jan 2015 12:44:20 +0000 (UTC) Received: (qmail 50262 invoked by uid 500); 10 Jan 2015 12:44:21 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 50194 invoked by uid 500); 10 Jan 2015 12:44:21 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 50184 invoked by uid 99); 10 Jan 2015 12:44:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 10 Jan 2015 12:44:21 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of trawick@gmail.com designates 209.85.217.173 as permitted sender) Received: from [209.85.217.173] (HELO mail-lb0-f173.google.com) (209.85.217.173) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 10 Jan 2015 12:44:17 +0000 Received: by mail-lb0-f173.google.com with SMTP id z12so11962553lbi.4 for ; Sat, 10 Jan 2015 04:43:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=7fULqLKHhP6sLWAYjpuBHXqFVeuTxvOhRWBhKK9sXmk=; b=1BI5r7MvW6JjkBVskClhWkuKawG9Rh7SI9PRVdpOB+cDtcQM9wCMwyuFsvTHhGUxWb mRFDkqGa8l8UAn47AAS/0Ep1D9Vdv6sxLoauJ1OPs8sGz/7oEStiDC/nzYfeeSGdqlR6 CZlr6aWhiwRuQNSj/3PQ5ojXYzf2fWXo4KFI/rnHB9BJFrAn8Kes066LT5Ux0eKvCDQG NGmgOErEdoPESJ+JZjCddN3q3mKptQZiG+8//Ew6/66nMrT9lhms22w30kiN76plrvzg VqNqNBwryEWhRsd4uFUxeWeBMhp1YrM4SYplAHoy+BtBcf2K2Vga+6riBj3xXQBWJpph gsVg== MIME-Version: 1.0 X-Received: by 10.152.6.67 with SMTP id y3mr26746216lay.90.1420893791073; Sat, 10 Jan 2015 04:43:11 -0800 (PST) Received: by 10.114.3.5 with HTTP; Sat, 10 Jan 2015 04:43:11 -0800 (PST) In-Reply-To: References: <20150109202313.GA8148@redhat.com> <54B04038.3010203@apache.org> Date: Sat, 10 Jan 2015 07:43:11 -0500 Message-ID: Subject: Re: CVE-2013-5704 fix breaks mod_wsgi From: Jeff Trawick To: Apache HTTP Server Development List Content-Type: multipart/alternative; boundary=089e01494046ae3a41050c4b9d45 X-Virus-Checked: Checked by ClamAV on apache.org --089e01494046ae3a41050c4b9d45 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jan 9, 2015 at 5:04 PM, Graham Dumpleton 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 th= ey > 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 advan= ce > 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 caterin= g > 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 ho= w > much I do need it and whether I can eliminate it and find other ways to d= o > 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 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>> 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 daem= on >> > mode, notably that it allocates a request_rec internally which end= s >> 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 <=3D 2.4.10 will allocate a request_rec >> using the >> > old, smaller "wrong" size, and hence, if such a build is used with >> >=3D >> > 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 kin= d >> 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 recompil= e >> a module that needs to do such things. >> > * Module authors who allocate structures generally created by httpd ow= n >> the monitoring and announcement, or should just >> > document "You must recompile this module every time you update httpd." >> > >> >> +1 >> >> Regards >> >> R=C3=BCdiger >> >> > --=20 Born in Roswell... married an alien... http://emptyhammock.com/ --089e01494046ae3a41050c4b9d45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 9, 2015 at 5:04 PM, Graham Dumpleton <grahamd@apache.org>= wrote:
Thanks fo= r 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 suffic= ient given than my direct use of request_rec isn't going to populate th= e extra fields and they will remain NULL still. As trailers shouldn't b= e expected in context the request_rec is being used directly by mod_wsgi th= ose attributes shouldn't be touched, but if that is the case, why would= it be crashing without recompilation happening. So need to also actually v= erify whether it can't limp on as is for now if it isn't crashing.<= br>

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 so= urce 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 poin= ter. 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 up= dated.

4. Work on more permanent solution. The pos= sibility of API functions for creating the structures has been suggested bu= t 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_r= ec 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 possi= ble to do away with it.

I can&#= 39;t speak specifically to more creators of request_rec, but there are othe= r cases (alternative mass vhost implementations come to mind, guiltily I mi= ght add) where the only apparent solution is to build one of these key stru= ctures.
=C2=A0

Thanks again for giving consideration for the proble= m I have caused.
<= br>
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:<= a href=3D"mailto:jorton@redhat.com" target=3D"_blank">jorton@redhat.com= >> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Since Jim is talking 2.4.11, I should report this n= ow.=C2=A0 We discovered
>=C2=A0 =C2=A0 =C2=A0this week in Fedora: mod_wsgi does some interesting= things in daemon
>=C2=A0 =C2=A0 =C2=A0mode, notably that it allocates a request_rec inter= nally which ends up
>=C2=A0 =C2=A0 =C2=A0getting used by httpd.
>
>=C2=A0 =C2=A0 =C2=A0Reason is, the fix for CVE-2013-5704 extends the re= quest_rec:
>
>=C2=A0 =C2=A0 =C2=A0http://svn.apache.org/r1619884
>
>=C2=A0 =C2=A0 =C2=A0A mod_wsgi built against <=3D 2.4.10 will alloca= te a request_rec using the
>=C2=A0 =C2=A0 =C2=A0old, smaller "wrong" size, and hence, if = such a build is used with >=3D
>=C2=A0 =C2=A0 =C2=A02.4.11, it passes in the wrong-sized request_rec an= d that breaks later
>=C2=A0 =C2=A0 =C2=A0when httpd tries to access r->trailers_*.
>
>=C2=A0 =C2=A0 =C2=A0It's one of those fuzzy boundaries in the API, = you can argue mod_wsgi is
>=C2=A0 =C2=A0 =C2=A0wrong, but, I could argue it back; the struct *is* = public, not got a
>=C2=A0 =C2=A0 =C2=A0strong opinion on this personally.
>
>=C2=A0 =C2=A0 =C2=A0Either way, the fix for CVE-2013-5704 ends up break= ing backwards
>=C2=A0 =C2=A0 =C2=A0compatibility with existing 2.4.x builds of mod_wsg= i, which is kind of
>=C2=A0 =C2=A0 =C2=A0Bad.=C2=A0 I don't have a good proposal for how= to fix or avoid this.=C2=A0 Worst
>=C2=A0 =C2=A0 =C2=A0case, we make clear the mod_wsgi case is API/ABI ab= use and warn binary
>=C2=A0 =C2=A0 =C2=A0distributors they have to handle this by rebuilding= .
>
>=C2=A0 =C2=A0 =C2=A0Regards, Joe
>
>
> * One-time only: Make clear in announcement that mod_wsgi has to be re= built.
> * Add helper functions to allocate a request_rec, conn_rec, server_rec= .=C2=A0 It doesn't solve all possible problems of
> course but can drastically reduce the frequency of needing to recompil= e a module that needs to do such things.
> * Module authors who allocate structures generally created by httpd ow= n the monitoring and announcement, or should just
> document "You must recompile this module every time you update ht= tpd."
>

+1

Regards

R=C3=BCdiger





--
=
Born in Roswell... married = an alien...
http:= //emptyhammock.com/

--089e01494046ae3a41050c4b9d45--