Project

General

Profile

Actions

Feature #536

closed

add recursion to the SSI #include directive - patch included

Added by Anonymous about 18 years ago. Updated over 7 years ago.

Status:
Fixed
Priority:
Low
Category:
mod_ssi
Target version:
ASK QUESTIONS IN Forums:

Description

The following patch allow for recursion in SSI include directive (up to 25 in depth):


--- mod_ssi.c.dist      2006-02-10 13:33:00.000000000 -0500
+++ mod_ssi.c   2006-02-20 10:01:00.000000000 -0500
@@ -576,7 +576,24 @@
                                }
                                break;
                        case SSI_INCLUDE:
-                               chunkqueue_append_file(con->write_queue, p->stat_fn, 0, st.st_size);
+                               // do recursive SSI expansion
+
+                               // prevents infinite loop
+                               if (con->loops_per_request > 25 || buffer_is_equal(con->physical.path, p->stat_fn)) {
+                                       buffer_copy_string(srv->tmp_buf, "<!-- your include directives create an infinite loop;
 aborting -->");
+                                       chunkqueue_append_buffer(con->write_queue, srv->tmp_buf);
+                                       break;
+                               }
+
+                               tmp = buffer_init();
+                               buffer_copy_string_buffer(tmp, con->physical.path); // save path of current document
+                               buffer_copy_string_buffer(con->physical.path, p->stat_fn); // next sub-document to parse
+                               if (mod_ssi_physical_path(srv,con,p) != HANDLER_FINISHED) {
+                                       // the document was not processed, so write it as is
+                                       chunkqueue_append_file(con->write_queue, con->physical.path, 0, st.st_size);
+                               }
+                               buffer_copy_string_buffer(con->physical.path, tmp); // restore saved path
+                               buffer_free(tmp);
                                break;
                        }
                } else {
@@ -1046,6 +1063,8 @@

        if (con->physical.path->used == 0) return HANDLER_GO_ON;

+       con->loops_per_request++;
+
        mod_ssi_patch_connection(srv, con, p);

        for (k = 0; k < p->conf.ssi_extension->used; k++) {

-- marc


Files

lighttpd.ssi.patch (1.77 KB) lighttpd.ssi.patch updated patch for lighttpd 1.4.11 -- dhazeghi Anonymous, 2006-06-04 18:36
mod_ssi.c.diff (2.71 KB) mod_ssi.c.diff SSI_INCLUDE recursion patch WITH code for ssi.max_recursion option -- marc Anonymous, 2007-02-28 17:26
mod_ssi.c.2.diff (2.71 KB) mod_ssi.c.2.diff same as previous, with ssi.max_recursion default value set to 1 -- marc Anonymous, 2007-02-28 17:29
mod_ssi.patch (3.32 KB) mod_ssi.patch Add missing mod_ssi.h modifications -- marc Anonymous, 2007-02-28 18:23
mod_ssi_recursion-1.4.15.patch (12.4 KB) mod_ssi_recursion-1.4.15.patch rerursive SSI for 1.4.15 -- dustin Anonymous, 2007-05-11 19:21
mod_ssi_recursion-1.4.15.2.patch (3.98 KB) mod_ssi_recursion-1.4.15.2.patch recursive SSI for 1.4.15 (minus whitespace garbage from previous patch) -- dustin Anonymous, 2007-05-11 19:34
mod_ssi-recursion-1.5.0svn2299.patch (3.42 KB) mod_ssi-recursion-1.5.0svn2299.patch Patch for this against 1.5.0-svn r2299. -- gw.lighttpd Anonymous, 2008-08-31 19:32
mod_ssi_recursion_1.5.0svn2299.patch (4.11 KB) mod_ssi_recursion_1.5.0svn2299.patch Correct recursion depth limit implementation Anonymous, 2008-09-02 16:15
lighttpd_ssi.patch (4.71 KB) lighttpd_ssi.patch Updated last patch for 1.4.29 eworm, 2011-12-08 22:05

Related issues 1 (0 open1 closed)

Related to Bug #2066: multiple patches for mod_ssiObsolete2009-09-14Actions
Actions #1

Updated by Anonymous over 17 years ago

Please make the 25 limit a configuration option, or use a different loop detection method. It's perfectly valid/safe to have one file which includes more than 25 ssi include statements. With this patch that is not possible.

-- rob

Actions #2

Updated by Anonymous about 17 years ago

The last patch included is against latest trunk (1.5.0). VERY EASY to apply against trunk.

-- marc

Actions #3

Updated by Anonymous over 16 years ago

I just installed the Windows version of lighttpd, LightTPD-1.4.16-Win32-NoSSL.exe (the ssl version didn't install, but that's another story). I downloaded it from http://wlmp.dtech.hu/. BTW, Why can't I find the windows version on the lighttpd site?

Anyways, SSI doesn't recurse. It runs the include in the top level page, but doesn't process the SSI in the included pages. I know it's not a screw up in my SSI code because the site works fine on other servers, and I know it's not a config issue, because it does process the first page (unless there is some max-recurse setting? but I couldn't find one).

here's my version info:
brian@brian-PC /cygdrive/c/LightTPD
$ ./LightTPD.exe -v
LightTPD-1.4.16 (Win32)
A fast, secure and flexible webserver...

This version is built for WLMP Project - http://wlmp.dtech.hu/
Build-Date: Jul 27 2007 10:32:13

Maybe I should be talking to the WLMP people instead of posting here? It seems that I've got a version that should have this bug fixed though.

The (P.O.S.) operating system is Windows Vista if it matters.

Oh!, and I just remembered, I also installed the cygwin version (through the cygwin installer, but have since uninstalled it), ... It was version 1.4.16-1. SSI didn't recurse using that cygwin version either, so it's not just some problem with that WLMP auto-installing executable version.

Thanks,

-brian

-- nairbv

Actions #4

Updated by darix over 16 years ago

there is a 3rd party patch which hasnt be included so far.
that said the issue is still open.

Actions #5

Updated by Anonymous over 16 years ago

The patch added 2007-05-11 19:34:07 "recursive SSI for 1.4.15 (minus whitespace garbage from previous patch)" inadvertently removed this line:


URIHANDLER_FUNC(mod_ssi_physical_path);

from around line 294, which causes it to fail to compile.

-- C Snover

Actions #6

Updated by Anonymous over 15 years ago

This really needs to be implemented! Not even 1.5.0-svn2282 has it.

A problem that arises from this actually makes SSI useless! Because you can not include another SSI file that uses variables you defined previously or split web page design into multiple layers of smaller building blocks. (Not everyone uses PHP for simple file inclusions, because it's overhead.)

In Apache the currently implemented behavior is for ``. To follow I think the patch is missing an if statement (to only use this nested includes if using virtual).

-- gw.lighttpd

Actions #7

Updated by Anonymous over 15 years ago

My previous patch is only a version of previous ones made to compile in 1.5.0-svn r2299, but it has a problem with SSI variables (they get reset) and as rob said 2 years ago it doesn't limit the depth of recursion (what would one expect from its name).

Therefore I made a new patch that implements the limitation of recursion depth correctly and also doesn't reset some structures at each include. It is avalible from: http://gw.tnode.com/0036-LighttpdDevelopment/Files-Patches/

But beware that this patch implements recursive SSI include virtual directives, but it doesn't limit the number of include directives per request. This means that someone who can create new pages can create a DoS page just by putting millions of include statements in it and freezing Lighttpd while it processes them (theoretically also possible with other instructions). This attack is also possible in the original mod_ssi implementation (so don't blame me)! It could be prevented by introducing a ssi.max_statements option that would count how many SSI statements were processed during a request and stop processing new ones when limit is hit. This issue should go in another ticket.

-- gw.lighttpd

Actions #8

Updated by kjikaqawej about 15 years ago

  • Target version changed from 1.5.0 to 1.4.22

These patches don't compile at all with 1.4.22. Seems mod_ssi_physical_path changed type, or should get an explicit cast:

mod_ssi.c: In function ‘process_ssi_stmt’:
mod_ssi.c:610: warning: implicit declaration of function ‘mod_ssi_physical_path’
mod_ssi.c: At top level:
mod_ssi.c:1132: error: conflicting types for ‘mod_ssi_physical_path’
mod_ssi.c:610: error: previous implicit declaration of ‘mod_ssi_physical_path’ was here
make3: * [mod_ssi.lo] Error 1
make3: Leaving directory `lighttpd/lighttpd-1.4.x-build/src'
make2:
[all] Error 2
make2: Leaving directory `lighttpd/lighttpd-1.4.x-build/src'
make1: *
* [all-recursive] Error 1
make1: Leaving directory `lighttpd/lighttpd-1.4.x-build'

This is with "mod_ssi_recursion-1.4.15.2.patch"

Well in the if statement, it gets used as an boolean (TRUE/FALSE) but it's declared (is that the right terminology?) as something else... obviously I don't have much clue, but I do know it doesn't compile ;).

Actions #9

Updated by kjikaqawej about 15 years ago

kjikaqawej wrote:

These patches don't compile at all with 1.4.22. Seems mod_ssi_physical_path changed type, or should get an explicit cast:

mod_ssi.c: In function ‘process_ssi_stmt’:
mod_ssi.c:610: warning: implicit declaration of function ‘mod_ssi_physical_path’
mod_ssi.c: At top level:
mod_ssi.c:1132: error: conflicting types for ‘mod_ssi_physical_path’
mod_ssi.c:610: error: previous implicit declaration of ‘mod_ssi_physical_path’ was here
make3: * [mod_ssi.lo] Error 1
make3: Leaving directory `lighttpd/lighttpd-1.4.x-build/src'
make2:
[all] Error 2
make2: Leaving directory `lighttpd/lighttpd-1.4.x-build/src'
make1: *
* [all-recursive] Error 1
make1: Leaving directory `lighttpd/lighttpd-1.4.x-build'

This is with "mod_ssi_recursion-1.4.15.2.patch"

Well in the if statement, it gets used as an boolean (TRUE/FALSE) but it's declared (is that the right terminology?) as something else... obviously I don't have much clue, but I do know it doesn't compile ;).

I've also tried the other patches, they all bomb out on my source tree - r2410 from the 1.4 branch - in more or less the same way. The other ways it bombs out is in addition to the error noted above, the compiler complains of redefinition of mod_ssi_physical_path, or other issues.

I changed that mod_ssi_physical_path to the 'tmp' defined above, and it compiles, but absolutely no SSI processing gets done.

Actions #10

Updated by icy about 15 years ago

  • Assignee deleted (jan)
  • Priority changed from High to Normal
  • Target version deleted (1.4.22)
  • Patch available set to Yes
Actions #11

Updated by kjikaqawej about 15 years ago

This patch Fails To Build. It's not resolved, though I'm going to try something.

Actions #12

Updated by kjikaqawej over 14 years ago

kjikaqawej wrote:

This patch Fails To Build. It's not resolved, though I'm going to try something.

Finally builds, was a bug in patching, due to having to port it forward, and some other issues.

It works, that's the good news, but there are some issues still, like disallowing "../foo.shtml", and not parsing .html included from the requested file (but IIRC apache also did that latter).

I don't have a patch yet, because a) I'm still testing b) it's changed a bit since, and I'm trying to get to do exactly what I want ;).

Thank you, BTW, to the people putting this up, for their work.

Actions #13

Updated by eworm over 12 years ago

I updated last patch for version 1.4.29. Any chance this will ever get merged?

Actions #14

Updated by gstrauss about 8 years ago

Instead of using con->loops_per_request, it would be clearer if a new member 'include_depth' were added to mod_ssi.h plugin_data and the count stored there.

It might be useful to set an inclusion limit on max num files included, rather than a recursion limit. Such a max num included files limit would limit total num files included and that would impose a max recursion limit as well.

Should con->uri.path be updated, too, for each processed 'virtual' inclusion?
Should DOCUMENT_NAME and DOCUMENT_URI change for each processed 'virtual' inclusion?
(I'm not saying they should or shouldn't be, but asking for the answer to be specified)

Actions #15

Updated by gstrauss about 8 years ago

@eworm: are you still interested in this patch? I'm willing to help get this patch ready.

Actions #16

Updated by gstrauss over 7 years ago

  • Related to Bug #2066: multiple patches for mod_ssi added
Actions #17

Updated by gstrauss over 7 years ago

  • Tracker changed from Bug to Feature
  • Priority changed from Normal to Low

@eworm: are you still interested in this patch? I'm willing to help get this patch ready.

Actions #18

Updated by gstrauss over 7 years ago

  • Status changed from New to Patch Pending
  • Target version changed from 1.4.x to 1.4.44
Actions #19

Updated by gstrauss over 7 years ago

  • Status changed from Patch Pending to Fixed
  • % Done changed from 0 to 100
Actions

Also available in: Atom