On Wed, May 20, 2009 at 8:53 AM, Joe Orton <jorton@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, <covener@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