mod_include and ap_expr

[Stefan Fritsch <sf...@sfritsch.de>]

Hi,

mod_include is still missing support for ap_expr. Trying to add that 
support raises some questions:

The mod_include expression parser tries hard to limit what can be done. 
For example, the subrequest operator -A can be switched of with a config 
option.  If mod_include was switched to ap_expr, this would open a lot of 
possibilities in the expression parser, like reading arbitrary files with 
the file() function, unrestricted file existance test, etc. I am not aware 
how mod_include is actually used in production, but if the *shtml files 
are untrusted, this could open a can of security problems. This is made 
even worse by the fact that modules can extend ap_expr. So, what kind of 
restrictions would be necessary for ap_expr in mod_include?

[ ] It would be enough to be able to switch back to the old, restricted
     expression parser.
[ ] All functions / operators should be classified into safe for
     mod_include or not safe for mod_include (with the classification being
     hard-coded).
[ ] One would need a detailed way to configure which functions /
     operators are allowed inside mod_include and which are not.


A different issue is that mod_include's parser is optimized for the 
expressions being parsed and then evaluated only once. ap_expr on the 
other hand is optimized for expressions being parsed once and then being 
evaluated often. Therefore it is possible that ap_expr would be slower in 
mod_include (but I haven't made any benchmark).

As I don't use mod_include, input from others would be very much 
appreciated.

Cheers,
Stefan

Re: mod_include and ap_expr

[Graham Leggett <mi...@sharp.fm>]

On 15 May 2011, at 3:18 PM, Stefan Fritsch wrote:

> Maybe the -A option was a bad example, then, because it allows only  
> access to resources that can be viewed directly, too. But ap_expr  
> would allow things like
>
> <!--#if expr="file('/etc/passwd') =~ /.../" >
>
> This only allows to leak one bit of the file contents per request,  
> but if used often enough, it could be used to reconstruct the whole  
> file. For .htaccess, this is not a new problem (see SSLRequire), but  
> for shtml files, it would be.

Hmmm...

In the mod_include case, having file() without having the file going  
through the normal httpd subrequest mechanism to determine whether the  
user has access to the file is indeed a security problem. The simplest  
would be to perhaps define a "restricted mode" for ap_expr, which  
disallowed certain dangerous functions.

You would enable restricted mode if you were parsing shtml,  
or .htaccess, but leave restricted mode disabled otherwise. Does that  
sound sensible?

Regards,
Graham
--

Re: mod_include and ap_expr

[Stefan Fritsch <sf...@sfritsch.de>]

On Sun, 15 May 2011, Graham Leggett wrote:
>> Do you think that untrusted shmtl files are not a common use case? In that 
>> case I would tend to the "people can always switch back to the old 
>> restricted expression syntax" solution.
>
> I don't follow what you mean by "untrusted shtml files"?

shtml files that are writable by users who are not allowed to read all 
files that httpd may have access to. .htaccess files have similar issues.

> What the -A option does is say "if this particular request for this URL would 
> succeed should this particular user attempt to access this particular URL 
> directly, then show this data". Or in English, you would use the -A option 
> within a page to show or hide links to something in a page depending on 
> whether that person has access to that link.

Maybe the -A option was a bad example, then, because it allows only 
access to resources that can be viewed directly, too. But ap_expr would 
allow things like

<!--#if expr="file('/etc/passwd') =~ /.../" >

This only allows to leak one bit of the file contents per request, but if 
used often enough, it could be used to reconstruct the whole file. For 
.htaccess, this is not a new problem (see SSLRequire), but for shtml 
files, it would be.

Re: mod_include and ap_expr

[Graham Leggett <mi...@sharp.fm>]

On 15 May 2011, at 1:22 PM, Stefan Fritsch wrote:

> So you implemented it more as a safeguard against confusion with "- 
> A" strings in existing expressions than as a security measure?

Yes.

> Do you think that untrusted shmtl files are not a common use case?  
> In that case I would tend to the "people can always switch back to  
> the old restricted expression syntax" solution.

I don't follow what you mean by "untrusted shtml files"?

What the -A option does is say "if this particular request for this  
URL would succeed should this particular user attempt to access this  
particular URL directly, then show this data". Or in English, you  
would use the -A option within a page to show or hide links to  
something in a page depending on whether that person has access to  
that link.

For example, to hide the link to JIRA from those that don't have  
access to JIRA, do this:

<!--#if expr="-A /jira/"-->
<tr><td><a href="/jira/secure/Dashboard.jspa?os_authType=basic">JIRA</ 
a></td><td><li></td></tr>
<!--#endif-->

It works the exact same way that mod_autoindex works, which also sets  
up subrequests to answer the question "should I display this  
particular file in the directory listing". If the subrequest returns  
some kind of error (>= 400), the module goes "oh well, access to that  
file not permitted, will leave it off the list".

Regards,
Graham
--

Re: mod_include and ap_expr

[Stefan Fritsch <sf...@sfritsch.de>]

On Sun, 15 May 2011, Graham Leggett wrote:
>> The mod_include expression parser tries hard to limit what can be done. For 
>> example, the subrequest operator -A can be switched of with a config 
>> option.
>
> If it makes your life easier to remove this config option please do - it was 
> only put there to make it possible to backport the -A option to v2.2 while 
> guaranteeing no existing configs could break. In v2.4 this option doesn't 
> make much sense.

So you implemented it more as a safeguard against confusion with "-A" 
strings in existing expressions than as a security measure? Do you think 
that untrusted shmtl files are not a common use case? In that case I would 
tend to the "people can always switch back to the old restricted 
expression syntax" solution.

Cheers,
Stefan

Re: mod_include and ap_expr

[Graham Leggett <mi...@sharp.fm>]

On 15 May 2011, at 12:51 PM, Stefan Fritsch wrote:

> The mod_include expression parser tries hard to limit what can be  
> done. For example, the subrequest operator -A can be switched of  
> with a config option.

If it makes your life easier to remove this config option please do -  
it was only put there to make it possible to backport the -A option to  
v2.2 while guaranteeing no existing configs could break. In v2.4 this  
option doesn't make much sense.

Regards,
Graham
--