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.
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...
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.org yourself? I could chase it for you, otherwise.
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.
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).
Created attachment 335600 [details] cleaned up assessment chart
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.
To answer your other question - no, this hasn't been reported upstream yet.
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?
(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
(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
Created attachment 340603 [details] upstream proposed patch to fix the issue
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.
Created attachment 340605 [details] test suite output post-patch
Created attachment 340606 [details] quick-and-dirty test-suite
(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... :-)
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...
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.
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.
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.
(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...
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.
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"
Public: http://marc.info/?l=apache-httpd-dev&m=124048996106302&w=2
This has been assigned CVE-2009-1195.
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 was getting from his tests... Darn it I just found another directory where someone had set AllowOverride Options=Includes for no good reason...
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.
Created attachment 341203 [details] fixed test-suite
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.
Oh, Jon's comments are in comment 30 as well as in private mail.
(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...
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.
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
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
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
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
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
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.