Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of jorton@redhat.com designates
 66.187.237.31 as permitted sender)
Date: Fri, 22 May 2009 17:28:01 +0100
From: Joe Orton <jorton@redhat.com>
To: Jeff Trawick <trawick@gmail.com>, dev@httpd.apache.org,
        modperl@perl.apache.org
Subject: Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES
	STATUS include/http_core.h modules/filters/mod_include.c
	server/config.c server/core.c
Message-ID: <20090522162801.GA1616@redhat.com>
Mail-Followup-To: Jeff Trawick <trawick@gmail.com>, dev@httpd.apache.org,
	modperl@perl.apache.org
References: <20090512131730.1F03F2388842@eris.apache.org>
 <cc67648e0905170815u640bbaf6j302dd35f1b29847@mail.gmail.com>
 <20090520125319.GB2601@redhat.com>
 <cc67648e0905211139k3dc293cbyfc2dea28067416b5@mail.gmail.com>
 <20090522162607.GA26770@redhat.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="sm4nu43k4a2Rpi4c"
Content-Disposition: inline
In-Reply-To: <20090522162607.GA26770@redhat.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor,
 Berkshire, SL4 1TE, United Kingdom.
  Registered in UK and Wales under Company Registration No. 03798903
  Directors: Michael Cunningham (USA), Brendan Lane (Ireland),
 Matt Parson (USA), Charlie Peters (USA)


--sm4nu43k4a2Rpi4c
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

On Fri, May 22, 2009 at 05:26:07PM +0100, Joe Orton wrote:
> Attaching my original analysis for security@ which hopefully answers 
> that question ;)

attempt 2

--sm4nu43k4a2Rpi4c
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename="ssi.foo"


I've now had a deeper look into this.  I can't see a way to fix the 
problem without changing the semantics of the OPT_ bits used, as I 
mentioned briefly in my comment to Vincent.

Status quo:

a) OPT_INCLUDES is interpreted as "SSI is allowed with exec="

b) OPT_INCNOEXEC is interperted iff OPT_INCLUDES is also set as meaning
   "SSI is allowed but exec= is not"

c) setting "AllowOverride Options=IncludesNoExec" results in both
OPT_INCLUDES and OPT_INCNOEXEC being set in the ->override_opts bitmask, 
i.e. either or both options can be overridden in .htaccess files

>From this leads the fact that an .htaccess file can set simply "Options 
Includes" in a context which inherits "AllowOverride 
Options=IncludesNoExec".  I'm presuming nobody will argue that's a 
feature not a bug?

If so, I think this is the set of constraints which need to be 
satisfied:

1) the result of a config merge with only "Options IncludesNoEXEC"
   specified must not allow use of exec= in SSI

2) if "AllowOverride Options=" is used without "Includes", notably, 
   use of "AllowOverride Options=IncludesNoExec", use of 
   "Options Includes" in an .htaccess file must be an error

3) if "AllowOverride Options=Includes" is set, use of both 
   "Options Includes" and "Options IncludesNoExec" must
   succeed and enable SSI with or without exec= respectively

4) if permitted by AllowOverride, setting "Options Includes" in 
   a context from which "Options IncludesNoExec" is inherited, then
   the result must be one where exec= is allowed.

Attached is a patch which passes the tests I have so far - Vincent, can 
you easily re-run your tests used to produce that lovely matrix, with 
this applied?

Regards, Joe


--sm4nu43k4a2Rpi4c--