config/5180: IncludesNoExec on Options do not allow to use SSI with a php3 page EVEN if it is protected

[Raul Dias <ap...@dias.com.br>]

>Number:         5180
>Category:       config
>Synopsis:       IncludesNoExec on Options do not allow to use SSI with a php3 page EVEN if it is protected
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Thu Oct 21 09:50:01 PDT 1999
>Last-Modified:
>Originator:     apache_bug@dias.com.br
>Organization:
apache
>Release:        all (that support mod_php)
>Environment:
Conectiva Linux 4.0 (RH 6.0 clone).
Apache 1.3.6 (this is not related to this specific version)
Kernel 2.2.13
mod_php3 3.0.12 (with mysql support)
>Description:
Ok, this is not really a bug, but a configuration issue.

The usual behavior for SSI and a php3 page is to let 
<!--#include virtual="page_script.php3" -->

work only if the dir with the SSI (.shtml) page has the "Options Includes" enable.

If instead it has "Options IncludesNoExec" enable, it will not work.
This is obviously correct.
A PHP page is a potential security risk, as a user may use something like 
system();, popen();, exec();...

However, and this is the whole point, the mod_php3 engine can be turned on and off
per <Directory> basis.

Consider the situation:
The mod_php's php3.ini (config) file has the Engine option in Off.
In httpd.conf there is a configuration like this:

<Diretory "/www_root/php">
	php3_engine on
</Directory>

In this situation the dir .../php will behave like an /cgi-bin/ but for php pages.
The users do not have access to it, and they cannot publish PHP3 pages.
In this situation the exec threat the a regular php3 imposes will be handled by the 
webmaster/sysadmin/...

However the only way users would access then (with SSI) is with "Options Includes" 
enable for them, which will cause a major risk for the server.

"Options IncludesNoExec" allow users to use SSI to include a CGI, so that's the same situation.

The point here is, why not implement the same scripts as regulars CGIs?
because of the overhead.  Using a regular.php3 page is faster (really faster if you 
use php4) than a regualar CGI script, even a PHP CGI SCRIPT (#!/usr/bin/php)

Users have access to counters, guest books, and other scripting dynamic content pages.
Using mod_php3 turns it really in low load to the server.

With the grow of PHP and MOD_PERL (I don't know how does it behave in the same situation)
people will start to have the same problem, and some might even allow exec in SSI 
to be able to use this kind of feature.

What I suggest is not to make Includes accept all PHP pages, but to use a 
directive (probably a new one) that would tell Apache what is to be 
considered EXEC in SSI and, what is not.
>How-To-Repeat:
Just try the code.
In httpd.comf:

<Diretory "somewher/in_your/root_docs">
	Options IncludesNoExec
</Directory>

And create a SSI page in somewher/in_your/root_docs, like page.shtml.
And Include the following:
<!--#include virtual="page.php3" -->

Note that you will need a page.php3 too, but it can even be blank.
>Fix:

Use a directive (probably a new one) that would tell Apache what is to be 
considered EXEC in SSI and, what is not.
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, you need]
[to include <ap...@Apache.Org> in the Cc line and make sure the]
[subject line starts with the report component and number, with ]
[or without any 'Re:' prefixes (such as "general/1098:" or      ]
["Re: general/1098:").  If the subject doesn't match this       ]
[pattern, your message will be misfiled and ignored.  The       ]
["apbugs" address is not added to the Cc line of messages from  ]
[the database automatically because of the potential for mail   ]
[loops.  If you do not include this Cc, your reply may be ig-   ]
[nored unless you are responding to an explicit request from a  ]
[developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]