Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 71762 invoked from network); 4 Feb 2004 15:54:36 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 4 Feb 2004 15:54:36 -0000 Received: (qmail 14548 invoked by uid 500); 4 Feb 2004 15:54:20 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 14509 invoked by uid 500); 4 Feb 2004 15:54:20 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 14468 invoked from network); 4 Feb 2004 15:54:19 -0000 Received: from unknown (HELO main.gmane.org) (80.91.224.249) by daedalus.apache.org with SMTP; 4 Feb 2004 15:54:19 -0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AoPM5-0003i1-00 for ; Wed, 04 Feb 2004 16:54:21 +0100 Received: from 212.222.194.100 ([212.222.194.100]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed Feb 4 15:54:21 2004 Received: from jh by 212.222.194.100 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed Feb 4 15:54:21 2004 X-Injected-Via-Gmane: http://gmane.org/ To: dev@cocoon.apache.org From: Jorg Heymans Subject: Re: variable substitution in @type attributes Date: Wed, 04 Feb 2004 16:52:21 +0100 Lines: 22 Message-ID: References: <40211274.7080701@apache.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.222.194.100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en In-Reply-To: <40211274.7080701@apache.org> Sender: news X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N > > Moreover, the use case shows a component type coming directly for the > request URI, which is a giant door open to "component injection" by > providing a value for the type that is not in the expected values and > executes arbitrary code on the server. Wooo hold on here, what you just described sounds a bit like a buffer overflow type of exploit, a bit of overkill i think. Granted, if i can 1) upload my component 2) reload/restart the servlet container 3) get my components initialize() to run then i'm in business. But how feasible is this? Worst case would be if the user configured fileuploads to go to web-inf/lib or web-inf/classes but then you're in trouble anyway because i'll upload my custom servlet class that overwrites the cocoon servlet. Understanding your concerns, but needing a higher than extremely unlikely and isolated usecase, Jorg