cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: variable substitution in @type attributes
Date Wed, 04 Feb 2004 16:11:15 GMT
Jorg Heymans wrote:

>> 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,

That's not unlikely and doesn't require uploading classes. Consider the 
<map:match pattern="*-*.html">
  <map:generate src="repository/{1}.xml" type="file"/>
  <map:transform type="{2}"/>
  <map:serialize type="html"/>

Now suppose we're in a CMS and that the user can upload the initial xml 
file. What if {2}, which is expected to be "foo" or "bar" is set to 
"jxtemplate"? The uploaded file iss interpreted and can then execute 
arbitrary code on the server!

Does this sound so unlikely?


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message