On Wed, May 20, 2009 at 8:53 AM, Joe Orton <jor...@redhat.com> wrote:
> On Sun, May 17, 2009 at 11:15:00AM -0400, Jeff Trawick wrote: > > On Tue, May 12, 2009 at 9:17 AM, <cove...@apache.org> wrote: > > > > > Author: covener > > > Date: Tue May 12 13:17:29 2009 > > > New Revision: 773881 > > > > > > URL: http://svn.apache.org/viewvc?rev=773881&view=rev > > > Log: > > > backport 772997, 773322, 773342 from trunk. > > > Reviewed By: jorton, rpluem, covener > > > > > > Security fix for CVE-2009-1195: fix Options handling such that > > > 'AllowOverride Options=IncludesNoExec' does not permit Includes with > > > exec= enabled to be configured in an .htaccess file: > > > > > > * include/http_core.h: Change semantics of Includes/IncludeNoExec > > > options bits to be additive; OPT_INCLUDES now means SSI is enabled > > > without exec=. OPT_INCLUDES|OPT_INC_WITH_EXEC means SSI is enabled > > > with exec=. > > > > > > Current mod_perl tarballs reference OPT_INC_WITH_EXEC as part of mapping > the > > httpd API into perl, and the mod_perl build fails because of this. > > > > ("modperl_config.c", line 525: undefined symbol: OPT_INCNOEXEC) > > Ick :( For some reason I thought this was hidden by CORE_PRIVATE, for > what little that's worth. > > > While I don't understand why the mod_perl mappings are created at release > > time against who knows what httpd, it brings up an interesting httpd > issue > > anyway. > > > > If some module does have OPT_INCNOEXEC baked in (32), it matches what > > 2.2.12+ thinks is OPT_INC_WITH_EXEC. Similarly, the old > OPT_INC_WITH_EXEC > > (previously called OPT_INCLUDES), maps what 2.2.12+ thinks is > > OPT_INCLUDES-without-exec. > > > > We could swap the values of OPT_INCLUDES and OPT_INC_WITH_EXEC to lessen > the > > chance of some theoretical module making the wrong decision. > > > > We can also define OPT_INCNOEXEC to something (either the new > OPT_INCLUDES > > or "Get your mod_perl patch at XXX"). > > Given that the semantics of the options has changed, I don't think it's > worth changing httpd to maintain any pretence of compile-time or > run-time compatibility here. Any code using the OPT_* constants as > exposed by mod_perl cannot work as expected any more. > > Regards, Joe > Is the change in semantics required to fix the bug, or is it simply the current implementation? As these constants and the related ap_allow_options() have been exposed to the C API for eons, and passed through in API mappings such as mod_perl, it is worth making an alternate fix to avoid breaking module compiles and (potentially) module misbehavior when upgrading from 2.2.11 to 2.2.12. Unfortunately I don't have a patch :( Does somebody else care to share their opinion on this? Which of these are okay? - existing mod_perl releases (and potentially other third-party modules) won't compile with 2.2.12 - existing Perl modules (and potentially other third-party modules) will confuse include-with-exec and include-without-exec
