Bug 489436 - (CVE-2009-1195) CVE-2009-1195 httpd: AllowOverride Options=IncludesNoExec allows Options Includes
CVE-2009-1195 httpd: AllowOverride Options=IncludesNoExec allows Options Incl...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity high
: ---
: ---
Assigned To: Red Hat Product Security
source=bugzilla,public=20090422,repor...
: Security
Depends On: 499284 499285 505027 509781
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-09 22:00 EDT by Jonathan Peatfield
Modified: 2011-10-12 09:48 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-10-12 09:48:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
cleaned up assessment chart (4.23 KB, text/plain)
2009-03-17 17:06 EDT, Vincent Danen
no flags Details
upstream proposed patch to fix the issue (4.53 KB, patch)
2009-04-21 14:39 EDT, Vincent Danen
no flags Details | Diff
test suite output post-patch (4.31 KB, text/plain)
2009-04-21 14:48 EDT, Vincent Danen
no flags Details
quick-and-dirty test-suite (2.85 KB, text/plain)
2009-04-21 14:49 EDT, Vincent Danen
no flags Details
fixed test-suite (2.84 KB, text/plain)
2009-04-24 12:03 EDT, Vincent Danen
no flags Details
table of results for 2.2.x and RHEL5 2.2.3 (17.52 KB, text/html)
2009-04-29 09:41 EDT, Joe Orton
no flags Details
patch to fix the issue in apache 2.2.x (6.14 KB, patch)
2009-05-12 11:48 EDT, Vincent Danen
no flags Details | Diff

  None (edit)
Description Jonathan Peatfield 2009-03-09 22:00:42 EDT
Description of problem:

In an httpd.conf fragment like:

<Directory ...somepath...>
  AllowOverride ... Options=IncludesNoEXEC
</Directory>

that appears to limit what Options can be set in .htaccess to just IncludeNoexec, but in fact Options Includes is also allowed.  I assume that this is an upstream bug but I've not checked if any RH patches touch this part of the code.

Version-Release number of selected component (if applicable):

httpd-2.2.3-22.el5

How reproducible:

100%

Steps to Reproduce:
1. Add a <directory> which permits AllowOverride Options=IncludesNoEXEC
2. create a .htaccess in there and use Options Includes
3. access a file using ssi with #exec
  
Actual results:

the #exec is executed

Expected results:

includesnoexec only should be allowed ie no exec or cgi.

Additional info:

In the httpd source (as patched by the srpm etc), in server/core.c at about line 1288 we have the definition of set_allow_opts() which contains:

...
        else if (!strcasecmp(w, "Includes")) {
            opt = OPT_INCLUDES;
        }
        else if (!strcasecmp(w, "IncludesNOEXEC")) {
            opt = (OPT_INCLUDES | OPT_INCNOEXEC);
        }
...

I think that should probably be:

...
        else if (!strcasecmp(w, "Includes")) {
            opt = (OPT_INCLUDES | OPT_INCNOEXEC);
        }
        else if (!strcasecmp(w, "IncludesNOEXEC")) {
            opt = OPT_INCNOEXEC;
        }
...

since there is (as far as I can see) no harm allowing the user to specify IncludesNoExec if you allow them to use Includes but not the other way round.

Of course my understanding of the logic in set_options() might well be flawed but it seems that at least one of the bits set in override_opts must be set in opt to allow it so the change above looks to do what *I* would expect - though this might not be what others expect it to mean - ie I might well be misunderstanding what AllowOverride ... Options=IncludesNoEXEC should mean.
Comment 1 Jonathan Peatfield 2009-03-09 22:03:39 EDT
I should add that I've not even tried compiling with the changes I'm suggesting, as I've been trying to understand what is going on for the past 6 hours and it is now 2am here...
Comment 2 Joe Orton 2009-03-10 12:24:35 EDT
Hmmmm, interesting, thanks for reporting this.  This is certainly not something changed in the Red Hat package of httpd.   

Your analysis seems reasonable and compelling.  The fact that "AllowOverride Options=Includes" prevents use of "Options IncludesNoExec" is fairly nonsensical.

Would you like to report this to security@httpd.apache.org yourself?  I could chase it for you, otherwise.
Comment 3 Vincent Danen 2009-03-17 14:26:36 EDT
Reproduced with the following configuration:

add the following to httpd.conf:

<Directory "/var/www/html/test">
Options None
AllowOverride Options=IncludesNoEXEC
</Directory

In /var/www/html/test create the following two files:

index.shtml:
<html>
<body>
<p>
This document last modified <!--#flastmod file="front.shtml" -->
</p>
<p>Start include:</p>
<!--#include virtual="/test/test.shtml" -->
<p>End include</p>
</body></html>

test.shtml:
<html>
<body>
<p>start</p>
<pre>
<!--#exec cmd="pwd" -->
</pre>
<p>end</p>
</body>
</html>

With no .htaccess file, loading index.shtml displays "[an error occurred while processing this directive]" and the logs show:

[Tue Mar 17 09:12:29 2009] [error] [client 192.168.250.50] exec used but not allowed in /var/www/html/test/test.shtml

Adding a .htaccess file consisting of:

Options +Includes

will show the directory name when loading index.shtml.

According to the apache manual:

Includes
    Server-side includes are permitted.
IncludesNOEXEC
    Server-side includes are permitted, but the #exec command and #exec CGI are disabled. It is still possible to #include virtual CGI scripts from ScriptAliase'd directories

So this is effectively elevating privileges against what the server administrator permits.

But there seems to be a bit more here.  When you use "Options +IncludesNoEXEC" in the .htaccess, the #exec still works.  If you have IncludesNoEXEC in the <Directory> container and .htaccess, the #exec is still executed.

I also tried the above proposed solution of changing 'opt = (OPT_INCLUDES | OPT_INCNOEXEC)' to 'opt = OPT_INCNOEXEC' and it seems like it might work, but I would prefer a review upstream.  With the first-noted <Directory> configuration and a .htaccess containing "Options +Includes", it pushes an internal server error with:

[Tue Mar 17 10:03:33 2009] [alert] [client 192.168.250.50] /var/www/html/test/.htaccess: Option Includes not allowed here

in the logs.  However, it doesn't fully fix the issue, because you can use:

<Directory "/var/www/html/test">
Options IncludesNoEXEC
AllowOverride Options=IncludesNoEXEC
</Directory>

and in .htaccess use "Options +IncludesNoEXEC" and the #exec is still executed (which is obviously incorrect).

Has this been reported upstream at all yet?

Oh, and as an aside, the "AllowOverride ... Options=IncludesNoEXEC" means that the .htaccess file can override or set that Options option (i.e. if it's disabled or enabled in httpd.conf it can be overridden or set in .htaccess).

Also note that Options= support was only introduced in Apache 2.2.

Finally, there is some very wierd logic here that I'm trying to wrap my head around.  I'll try to summarize it in a bit once I fully understand it because it seems there are strange things that happen between Options and AllowOverride settings in <Directory> containers and how they interact with stuff set in .htaccess.
Comment 4 Vincent Danen 2009-03-17 16:48:43 EDT
Ok, I think I grok this a bit more now.

I tried with httpd in RHEL5 and also with httpd patched with the above patch suggestion.  My chart is too big to put here so I'll add it as an attachment so you can see the thinking behind my conclusion, but I believe we definitely have a problem here that goes beyond config wierdness.

There are basically three points of configuration:

- Options (in <Directory>)
- AllowOverride settings (in <Directory>)
- Options (in .htaccess)

Options sets the available options for the directory.  AllowOverride *allows* for options to be overridden via .htaccess, and Options in .htaccess actually does the overriding.  The overrides can be done in two ways: using KeyName (i.e. "IncludesNoExec") or using +KeyName; the first sets the option explicitly, the second *merges* that option with the more explicit options.

So I tested with every combination of Options (None, Includes, IncludesNoExec), AllowOverride (None, All, Option=IncludesNoExec, Option=Includes), and Options settings in .htaccess (+Includes, +IncludesNoExec (these I tried as both explicit and merged)).

I found three scenarios where Apache allows #exec where it shouldn't:

- Options None; AllowOverride Option=IncludesNoExec, Options +Includes (.htaccess): this is elevating because we have no options set and we only allow IncludesNoExec to be overridden (yet we can override Includes) - the above patch suggestion fixes this by creating an internal server error (log: Includes not allowed)
- Options IncludesNoExec; AllowOverride Option=IncludesNoExec; Options +Includes (.htaccess): same as above, we should not be able to override Includes
- Options IncludesNoExec; AllowOverride Option=IncludesNoExec; Options +IncludesNoExec (.htaccess): this one is funny; if you use +IncludesNoExec then #exec is executed, but if you use IncludesNoExec (no +) then it is not

So we definitely have an issue here as users should not be able to elevate their privileges like this.

Also note that the last issue (the odd one) is _NOT_ corrected by the above patch suggestion.  I'm also not sure if there would be any other regressions or negative impact to that change, so I think upstream would be best to come up with the appropriate fix (although I think the last one is more bad logic than anything else).
Comment 6 Vincent Danen 2009-03-17 17:06:17 EDT
Created attachment 335600 [details]
cleaned up assessment chart
Comment 7 Joe Orton 2009-03-17 17:55:07 EDT
Excellent analysis, thanks Vincent!

I think the extra problem you have identified is because the bitflags have the wrong semantics: they need to be additive, but OPT_INCNOEXEC is not.

two flags:  OPT_INCLUDES => "includes are permitted, but not with exec="
            OPT_INCLUDES_WITH_EXEC => "exec= is also allowed"

would work, with mod_include only allowing exec if *both* flags are present.  It's the fact that mod_include is testing for the absence of the bit to allow exec which is screwing this up.
Comment 8 Joe Orton 2009-03-17 17:59:08 EDT
To answer your other question - no, this hasn't been reported upstream yet.
Comment 9 Vincent Danen 2009-03-17 18:14:49 EDT
Ahhh.. I thought it must be something like that.  Glad to see I wasn't wrong.

Did you want to send this upstream or should I?
Comment 10 Jonathan Peatfield 2009-03-18 06:59:24 EDT
(In reply to comment #9)
> Ahhh.. I thought it must be something like that.  Glad to see I wasn't wrong.
> 
> Did you want to send this upstream or should I?  

It would probably be better comming from you - I know almost nothing about the httpd code base and only discovered the problems because we (accidentally as it happens) configured a server with one of the bad set of options= settings...

 -- Jon
Comment 11 Jonathan Peatfield 2009-03-18 07:05:24 EDT
(In reply to comment #7)
> Excellent analysis, thanks Vincent!
> 
> I think the extra problem you have identified is because the bitflags have the
> wrong semantics: they need to be additive, but OPT_INCNOEXEC is not.
> 
> two flags:  OPT_INCLUDES => "includes are permitted, but not with exec="
>             OPT_INCLUDES_WITH_EXEC => "exec= is also allowed"
> 
> would work, with mod_include only allowing exec if *both* flags are present. 
> It's the fact that mod_include is testing for the absence of the bit to allow
> exec which is screwing this up.  

Or just have 2 completely unrelated bits - this is how the followsymlinks and symlinksifownermatch stuff seems to be done - with the code checking for either bit being set to allow symlink following and one bit haveing the more restrictive meaning.

In any case the current code is clearly more complex than I realised - there are other places where these bit fields get manipulated and that may be what is leading to the last case where +IncludesNoExec allos #exec...

Clearly this is best corrected by someone who is very familiar with the rest of the httpd code...

 -- Jon
Comment 16 Vincent Danen 2009-04-21 14:39:57 EDT
Created attachment 340603 [details]
upstream proposed patch to fix the issue
Comment 17 Vincent Danen 2009-04-21 14:46:11 EDT
Well, I've tested with the above patch and the only difference pre-patch to post-patch is:

--- pre-patch	2009-04-21 10:53:31.000000000 -0700
+++ post-patch	2009-04-21 11:28:18.000000000 -0700
@@ -39,7 +40,7 @@
 
   Testing with httpd.conf AllowOverride All
     + .htaccess: +Includes... result: exec  (options=IncludesNoExec, allowoverride=All, htaccess=+Includes)
-    + .htaccess: +IncludesNoExec... result: exec  (options=IncludesNoExec, allowoverride=All, htaccess=+IncludesNoExec)
+    + .htaccess: +IncludesNoExec... result: noexec (fail)
     + .htaccess: Includes... result: exec  (options=IncludesNoExec, allowoverride=All, htaccess=Includes)
     + .htaccess: IncludesNoExec... result: noexec (fail)
 
@@ -64,7 +65,7 @@
 
   Testing with httpd.conf AllowOverride All
     + .htaccess: +Includes... result: exec  (options=Includes, allowoverride=All, htaccess=+Includes)
-    + .htaccess: +IncludesNoExec... result: noexec (fail)
+    + .htaccess: +IncludesNoExec... result: exec  (options=Includes, allowoverride=All, htaccess=+IncludesNoExec)
     + .htaccess: Includes... result: exec  (options=Includes, allowoverride=All, htaccess=Includes)
     + .htaccess: IncludesNoExec... result: noexec (fail)


But this is with an automated test-suite I wrote this morning, but I'm thinking there is something wrong with it because it's not providing the same results as what I got when I did the testing manually (although I'm not sure why)

I'm not sure about the second bit, however.  It was failing to exec before, and now it is exec'ing (with Options Includes, AllowOverride All, and +IncludesNoExec in .htaccess... shouldn't IncludesNoExec override Includes?).

I'll also attach the full output of the test suite post-patch and the test suite itself.
Comment 18 Vincent Danen 2009-04-21 14:48:23 EDT
Created attachment 340605 [details]
test suite output post-patch
Comment 19 Vincent Danen 2009-04-21 14:49:12 EDT
Created attachment 340606 [details]
quick-and-dirty test-suite
Comment 20 Jonathan Peatfield 2009-04-21 19:34:33 EDT
(In reply to comment #17)
> Well, I've tested with the above patch and the only difference pre-patch to
> post-patch is:
> 
...
> 
> But this is with an automated test-suite I wrote this morning, but I'm thinking
> there is something wrong with it because it's not providing the same results as
> what I got when I did the testing manually (although I'm not sure why)

Which combinations are different?  I'm afraid that reading though the tables I couldn't spot what was 'diffferent'...

> I'm not sure about the second bit, however.  It was failing to exec before, and
> now it is exec'ing (with Options Includes, AllowOverride All, and
> +IncludesNoExec in .htaccess... shouldn't IncludesNoExec override Includes?).

Well having read the patch I can see why it allows exec since it starts with Includes which does:

  opt = (OPT_INCLUDES | OPT_INC_WITH_EXEC)

then AllowOverride All allows all the bits to be altered, and +IncludesNoExec will or in OPT_INCLUDES so we still end up with both bits set but IncludesNoExec (no plus) in .htaccess will set opt to OPT_INCLUDES and disable exec...

I'm not sure that is expected in this case but +option normally adds (ORs) the bits so doesn't disable other options which were set higher up.

On the other hand if the .htaccess didn't do +IncludesNoExec then exec would also be allowed so this isn't allowing the user to bypass the admin options.

In any case I wouldn't like to be the one who has to write the doco describing all these interactions.

I bet that if you were to test the interactions of FollowSymlinks and SymlinkIfOwnerMatch bits you may find at least one counter-intuitive combination as well.

> 
> I'll also attach the full output of the test suite post-patch and the test
> suite itself.  

Nice though the suite is, I think I'd be tempted to get it to generate a config listing a large number of directories for all the combinations so the resulting urls can then be re-checked by hand if they don't match expectations... :-)
Comment 21 Joe Orton 2009-04-22 04:40:26 EDT
Yeah, I've done as per that last comment based on Vincent's script...

http://people.apache.org/~jorton/ssi-exec/

vanilla-2.2.x.txt - results with 2.2.x
jorton-v1.txt - results with my patch (the one attached above)

columns are "httpd.conf Options, httpd.conf AllowOverride, .htaccess Options, results" with results explained in readme.txt.  There are a large swathe of changes so I think something was wrong with your tests Vincent.

The "Options Includes... Options +IncludesNoExec" case is an interesting one, yeah.  I want to get input from upstream on this; not getting any feedback on the private security list so far so I want to take it to the public list by the end of the week. (Presume that is OK with you, Jonathan?)  There are docs people on the public list who aren't on the private list...
Comment 22 Joe Orton 2009-04-22 04:45:17 EDT
Ah yes, Vincent in your script you had:

for allowoverride in "Options=IncludesNoExec" "Options=Includes" All None
...
     echo "AllowOverride Options=${allowoverride}"

which resulted in

   AllowOverride Options=Options=IncludesNoExec

which surprisingly wasn't a config error but didn't do what expected.
Comment 23 Vincent Danen 2009-04-22 13:29:56 EDT
Ah, good catch Joe.  I was wondering why it seemed off.

I'll re-run the tests and see if they better match up with the original chart this time.  Thanks.
Comment 24 Vincent Danen 2009-04-22 14:12:52 EDT
Ok, re-ran the tests and now the results jive with the original chart, both pre- and post-patch:

--- pre-patch	2009-04-22 10:57:26.000000000 -0700
+++ post-patch	2009-04-22 10:57:33.000000000 -0700
@@ -1,9 +1,9 @@
 Testing with httpd.conf Options None
 
   Testing with httpd.conf AllowOverride Options=IncludesNoExec
-    + .htaccess: +Includes... result: exec [**BAD**] (options=None, allowoverride=Options=IncludesNoExec, htaccess=+Includes)
+    + .htaccess: +Includes... result: noexec (internal server error)
     + .htaccess: +IncludesNoExec... result: noexec (fail)
-    + .htaccess: Includes... result: exec  (options=None, allowoverride=Options=IncludesNoExec, htaccess=Includes)
+    + .htaccess: Includes... result: noexec (internal server error)
     + .htaccess: IncludesNoExec... result: noexec (fail)
 
   Testing with httpd.conf AllowOverride Options=Includes
@@ -26,9 +26,9 @@ Testing with httpd.conf Options None
 Testing with httpd.conf Options IncludesNoExec
 
   Testing with httpd.conf AllowOverride Options=IncludesNoExec
-    + .htaccess: +Includes... result: exec [**BAD**] (options=IncludesNoExec, allowoverride=Options=IncludesNoExec, htaccess=+Includes)
+    + .htaccess: +Includes... result: noexec (internal server error)
     + .htaccess: +IncludesNoExec... result: exec [**BAD**] (options=IncludesNoExec, allowoverride=Options=IncludesNoExec, htaccess=+IncludesNoExec)
-    + .htaccess: Includes... result: exec [**BAD**] (options=IncludesNoExec, allowoverride=Options=IncludesNoExec, htaccess=Includes)
+    + .htaccess: Includes... result: noexec (internal server error)
     + .htaccess: IncludesNoExec... result: noexec (fail)
 
   Testing with httpd.conf AllowOverride Options=Includes
@@ -51,9 +51,9 @@ Testing with httpd.conf Options Includes
 Testing with httpd.conf Options Includes
 
   Testing with httpd.conf AllowOverride Options=IncludesNoExec
-    + .htaccess: +Includes... result: exec  (options=Includes, allowoverride=Options=IncludesNoExec, htaccess=+Includes)
+    + .htaccess: +Includes... result: noexec (internal server error)
     + .htaccess: +IncludesNoExec... result: noexec (fail)
-    + .htaccess: Includes... result: exec  (options=Includes, allowoverride=Options=IncludesNoExec, htaccess=Includes)
+    + .htaccess: Includes... result: noexec (internal server error)
     + .htaccess: IncludesNoExec... result: noexec (fail)
 
   Testing with httpd.conf AllowOverride Options=Includes

The only one that still seems like it should be corrected is when httpd.conf contains:

Options IncludesNoExec
AllowOverride Options=IncludesNoExec

and .htaccess has "+IncludesNoExec", it still executes (using "IncludesNoExec" does not).  I still think that whether IncludesNoExec or +IncludesNoExec is specified in that situation, it should not exec at all.  Other than that, I think it looks good.
Comment 25 Jonathan Peatfield 2009-04-22 14:36:45 EDT
(In reply to comment #21)
> The "Options Includes... Options +IncludesNoExec" case is an interesting one,
> yeah.  I want to get input from upstream on this; not getting any feedback on
> the private security list so far so I want to take it to the public list by the
> end of the week. (Presume that is OK with you, Jonathan?)  There are docs
> people on the public list who aren't on the private list...  

Given the weirdness of the bit combinations more eyes might help...  If only to find a way to describe things :-)

(In reply to comment #24)
...
> The only one that still seems like it should be corrected is when httpd.conf
> contains:
> 
> Options IncludesNoExec
> AllowOverride Options=IncludesNoExec
> 
> and .htaccess has "+IncludesNoExec", it still executes (using "IncludesNoExec"
> does not).  I still think that whether IncludesNoExec or +IncludesNoExec is
> specified in that situation, it should not exec at all.  Other than that, I
> think it looks good.  

Did you mean

  Options Includes
  AllowOverride Options=IncludesNoExec
  .htaccess has "+IncludesNoExec"

because otherwise this is even weirder than I thought possible - If IncludesNoExec is all that is ever mentioned I can't see how the new OPT_INC_WITH_EXEC bit is getting set - though I've not actually applied the upstream patch to see what the resulting files look like...
Comment 26 Vincent Danen 2009-04-22 14:47:46 EDT
Just double-checked, but no, I meant what I stated.  =)

Snippet from the diff above:

     + .htaccess: +IncludesNoExec... result: exec [**BAD**]
(options=IncludesNoExec, allowoverride=Options=IncludesNoExec,
htaccess=+IncludesNoExec)

You can see that all three options are IncludesNoExec (well, .htaccess has the "+" variant, but most definitely Options is set to IncludesNoExec).

Also note that the behaviour is unchanged by the patch: it did it before too.  However, if I look at the whole output of the test suite, using "IncludesNoExec" in .htaccess instead of "+IncludesNoExec" works properly.

Pre-patch:

Testing with httpd.conf Options IncludesNoExec

  Testing with httpd.conf AllowOverride Options=IncludesNoExec
    + .htaccess: +Includes... result: exec [**BAD**] (options=IncludesNoExec, allowoverride=Options=IncludesNoExec, htaccess=+Includes)
    + .htaccess: +IncludesNoExec... result: exec [**BAD**] (options=IncludesNoExec, allowoverride=Options=IncludesNoExec, htaccess=+IncludesNoExec)
    + .htaccess: Includes... result: exec [**BAD**] (options=IncludesNoExec, allowoverride=Options=IncludesNoExec, htaccess=Includes)
    + .htaccess: IncludesNoExec... result: noexec (fail)


Post-patch:

Testing with httpd.conf Options IncludesNoExec

  Testing with httpd.conf AllowOverride Options=IncludesNoExec
    + .htaccess: +Includes... result: noexec (internal server error)
    + .htaccess: +IncludesNoExec... result: exec [**BAD**] (options=IncludesNoExec, allowoverride=Options=IncludesNoExec, htaccess=+IncludesNoExec)
    + .htaccess: Includes... result: noexec (internal server error)
    + .htaccess: IncludesNoExec... result: noexec (fail)

Note that the patch fixes Includes/+Includes in .htaccess, but not +IncludesNoExec while IncludesNoExec always worked properly.
Comment 27 Joe Orton 2009-04-23 08:20:23 EDT
I'm not seeing that in my testing:

Options IncludesNoExec       AllowOverride Options=IncludesNoExec    Options +IncludesNoExec         200/ssi-noexec

with the patch applied.

vanilla 2.2.x was giving "200/ssi-exec"
Comment 29 Vincent Danen 2009-04-23 11:16:09 EDT
This has been assigned CVE-2009-1195.
Comment 30 Jonathan Peatfield 2009-04-23 19:13:52 EDT
If I take the RHEL5 srpm httpd-2.2.3-22.el5.src.rpm and rpmbuild -bp it and then apply the patch given above I get a server/core.c file which appears not to be as expected (by Joe Orton).

$ patch -p0 < ~/noexec.patch 
patching file server/config.c
Hunk #1 succeeded at 1492 (offset -18 lines).
Hunk #3 succeeded at 1737 (offset -18 lines).
patching file server/core.c
Hunk #1 succeeded at 110 (offset 2 lines).
Hunk #2 succeeded at 243 (offset 1 line).
Hunk #3 succeeded at 1302 (offset 1 line).
Hunk #4 succeeded at 1426 (offset 1 line).
patching file include/http_core.h
patching file modules/filters/mod_include.c
Hunk #1 succeeded at 3524 with fuzz 1 (offset -50 lines).

and the server/core.c font I have then contains starting at line 1407:

static const char *set_options(cmd_parms *cmd, void *d_, const char *l)
{
    core_dir_config *d = d_;
    allow_options_t opt;
    int first = 1;
    char action;
.....

        if (!(cmd->override_opts & opt) && opt != OPT_NONE) {
            return apr_pstrcat(cmd->pool, "Option ", w, " not allowed here", NULL);
...

but apparently it should read:

...
        if ( (cmd->override_opts & opt) != opt ) {
            return apr_pstrcat(cmd->pool, "Option ", w, " not allowed here", NULL);
...

which does change things quite a bit and may explain some of the different results that vdanen@redhat.com was getting from his tests...

Darn it I just found another directory where someone had set AllowOverride Options=Includes for no good reason...
Comment 31 Vincent Danen 2009-04-24 11:55:07 EDT
No, I don't think that was the problem with my test results.  The test-suite was wrong as Joe had pointed out.  Oh, that reminds me, I should attach the new/fixed one.
Comment 32 Vincent Danen 2009-04-24 12:03:08 EDT
Created attachment 341203 [details]
fixed test-suite
Comment 33 Joe Orton 2009-04-29 09:41:07 EDT
Created attachment 341751 [details]
table of results for 2.2.x and RHEL5 2.2.3

Jon pointed out in private mail that there's a difference between the RHEL5 2.2.3 code and the 2.2.x branch tip which I was testing - the difference is this fix:

http://svn.apache.org/viewvc?view=rev&revision=652885

so that does explain the remaining discrepancy between my results and Vincent's.

I'm attaching the test results I've got with "2.2.x tip" as the "Old result" column and "RHEL5 2.2.3" as the "New result" column.
Comment 34 Joe Orton 2009-04-29 09:42:24 EDT
Oh, Jon's comments are in comment 30 as well as in private mail.
Comment 35 Jonathan Peatfield 2009-04-29 12:01:57 EDT
(In reply to comment #33)
> Created an attachment (id=341751) [details]
> table of results for 2.2.x and RHEL5 2.2.3
> 
> Jon pointed out in private mail that there's a difference between the RHEL5
> 2.2.3 code and the 2.2.x branch tip which I was testing - the difference is
> this fix:
> 
> http://svn.apache.org/viewvc?view=rev&revision=652885
> 
> so that does explain the remaining discrepancy between my results and
> Vincent's.
> 
> I'm attaching the test results I've got with "2.2.x tip" as the "Old result"
> column and "RHEL5 2.2.3" as the "New result" column.  

From glancing at that patch it also seems to be a security issue since it allowed:

  Options All

in a .htaccess fragment if at least one AllowOverride Options=... bit was set (oops).

From the changes:

+  *) core: Do not allow Options ALL if not all options are allowed to be
+     overwritten. PR 44262 [Michał Grzędzicki <lazy iq.pl>]

The date on that changeset is 2008/05/02 so I don't know why that hadn't been flagged as a security fix and applied to the rhel5 tree earlier...
Comment 37 Vincent Danen 2009-05-12 11:48:20 EDT
Created attachment 343605 [details]
patch to fix the issue in apache 2.2.x

This patch corrects the issue in 2.2.10, 2.2.11.
Comment 38 Jonathan Peatfield 2009-05-12 12:41:34 EDT
Of course for the EL5x srpm (of 2.2.3) we also need the earlier patch mentioned in comment #33 (http://svn.apache.org/viewvc?view=rev&revision=652885) or the code will still allow Options All if any bit is set for the allowoverrides Options= stuff...

I think the following is a link to the actual required patch:

  http://svn.apache.org/viewvc/httpd/httpd/trunk/server/core.c?r1=645455&r2=652885&pathrev=652885

I don't know if that was ever assigned any kind of CVE or similar (it isn't obviously marked as a security fix in the changelog...)

 -- Jon
Comment 39 errata-xmlrpc 2009-05-27 10:19:53 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2009:1075 https://rhn.redhat.com/errata/RHSA-2009-1075.html
Comment 42 errata-xmlrpc 2009-07-14 15:07:05 EDT
This issue has been addressed in following products:

  JBEWS 1.0.0 for RHEL 5

Via RHSA-2009:1155 https://rhn.redhat.com/errata/RHSA-2009-1155.html
Comment 43 errata-xmlrpc 2009-07-14 15:07:59 EDT
This issue has been addressed in following products:

  Red Hat Web Application Stack for RHEL 5

Via RHSA-2009:1156 https://rhn.redhat.com/errata/RHSA-2009-1156.html
Comment 44 errata-xmlrpc 2009-07-17 09:13:43 EDT
This issue has been addressed in following products:

  JBEWS 1.0.0 for RHEL 4

Via RHSA-2009:1160 https://rhn.redhat.com/errata/RHSA-2009-1160.html
Comment 45 Fedora Update System 2009-08-31 19:39:14 EDT
httpd-2.2.13-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.