httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From wr...@rowe-clan.net
Subject RE: Re: CVE-2013-5704 fix breaks mod_wsgi
Date Tue, 13 Jan 2015 05:20:15 GMT
--------- Original Message --------- Subject: Re: CVE-2013-5704 fix breaks mod_wsgi
From: "Joe Orton" <jorton@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 <jorton@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.

Mime
View raw message