--------- Original Message --------- Subject: Re: CVE-2013-5704 fix breaks mod_wsgi From: "Joe Orton" <jor...@redhat.com> Date: 1/12/15 5:27 am To: "Graham Dumpleton" <grah...@apache.org> Cc: "dev@httpd.apache.org" <dev@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.
