cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robin Green" <>
Subject [SECURITY ADVISORY] Vulnerability in Cocoon default settings
Date Sat, 09 Sep 2000 21:35:14 GMT
This is a security advisory about a setting in the file 
which was shipped as standard in recent releases of Apache Cocoon. This 
setting, which refers to a Producer called ProducerFromRequest, could 
theoretically allow a malicious cracker under certain conditions to execute 
arbitrary Java code inside the virtual machine running Cocoon - and through 
the standard Runtime.exec() method in Java, execute operating system 
commands with the same privileges as the virtual machine running Cocoon.

Some concrete examples of the damage that could be done are:

* Defacing a website
* Deleting an entire website
* Erasing a database
* Obtaining confidential information such as database passwords

It affects the following versions of Apache Cocoon:

* 1.6 through 1.7.4 (current release), inclusive
* 1.8-dev, snapshots taken before July 15 2000

It also affects any site which has ProducerFromRequest - or a class similar 
in function - enabled as a Producer in a file.


Even more damage could of course be done if the Java virtual machine is 
running as user "root" (the superuser); but it is a very basic security 
precaution that no "Internet-facing" process should ever be run as root - 
indeed it should be given no more security permissions than absolutely 


1. Remove the line

producer.type.request = org.apache.cocoon.producer.ProducerFromRequest

from all copies of, and restart all servlet engines 
running Cocoon to effect the change. Since this Producer is inherently 
unsafe, it should be removed rather than commented out. Removing the file is also recommended, to prevent accidental use by 
new programmers.

Both the .java file and the entry will not be present in 
the upcoming release of Cocoon 1.8.

2. If similar functionality is required (reading XML from a HTTP request), 
write code in an xsp:logic block instead to perform the same task, using the 
implicit request and xspParser objects. Wrapping the read-in data in a 
wrapper element should ensure that the exploit described here cannot occur. 
However, careful validation is still advisable (as with non-XML input), in 
view of the fact that preventing various types of client-side exploits and 
server-side exploits from input data is a non-trivial problem (see the CERT 
website for more details on this).


Using the HTTP request parameter producer=request, a malicious cracker could 
potentially send an XSP page in the HTTP request body, allowing them to 
execute arbitrary Java code. This will not always work, if there is already 
a compiled page under that URL for example, but it is a possibility.


For further information, please first read messages on this subject on the mailing list. If your question still has not 
been answered, please post it to the list.


This advisory was written by Robin Green, a member of the Cocoon committer 
team. The flaw has been agreed as a genuine security problem by Stefano 
Mazzocchi and Donald Ball, project founder and Cocoon committer 

Get Your Private, Free E-mail from MSN Hotmail at

Share information about yourself, create your own public profile at

View raw message