cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robin Green" <gree...@hotmail.com>
Subject Why ProducerFromRequest is dangerous + How to do servlet chaining without it
Date Thu, 21 Sep 2000 22:15:13 GMT
I'm just reproducing two messages from earlier in the month for the benefit 
of those who missed them. Messages are separated by the lines of dashes.

-------------------------------------
This is a security advisory about a setting in the cocoon.properties 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 cocoon.properties file.


NOTE:

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
necessary.


HOW TO FIX:

1. Remove the line

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

from all copies of cocoon.properties, 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
ProducerFromRequest.java is also recommended, to prevent accidental use by
new programmers.

Both the .java file and the cocoon.properties 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).

DETAILS:

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.


FURTHER INFORMATION:

For further information, please first read messages on this subject on the
cocoon-users@xml.apache.org mailing list. If your question still has not
been answered, please post it to the list.


AUTHOR:

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
respectively.



-------------------------------------

How to Call Servlets, CGIs on your server and other servers; Servlet 
Chaining

A lot of people have asked about this recently. It's really SO SO simple
(and it's going in the new FAQ which is effectively a rewrite).

Unfortunately the 'answer' (or lack thereof) given in the current FAQ about
"servlet chaining" is either very misleading or just plain wrong, I don't
know which. Stefano?

What you DON'T do is use ProducerFromRequest - that's a security risk, as
noted in the recent Security Advisory which I can email to anyone who wants
it (it's also in the mail archives).

[A]. If the servlet or whatever you're calling returns XML, you can just do
this: (If not see [B] below).

1. Get the latest Cocoon from xml.apache.org/from-cvs or just from CVS
directly. 1.7.4 and below have a bug which prevents this from working.

2. Make an XSP page like this:

<?cocoon-process type="xsp"?>
<xsp:page xmlns:xsp="http://www.apache.org/1999/XSP/Core"
           xmlns:util="http://www.apache.org/1999/XSP/Util">
<page>
  <util:include-uri href="http://myserver.com/servlets/foo"/>
</page>
</xsp:page>

To build the URL dynamically just do something like this (if I remember
correctly):

<util:include-uri>
<util:href><xsp:expr>"http://myserver.com/servlets/foo?x=" + request.
getParameter ("foo")</xsp:expr></util:href>
</util:include-uri>

To include static XML files you can even use <util:include-file> (which is
faster), but only if the file is on the filesystem(s) of your server. There
are other options like XInclude and XML entities, but these should work
fine.


[B] To get data from non-XML sources, just do like in any Java program:

Object content = new URL ("http://myserver.com/foobar").getContent ();

or openStream(), or whatever is most appropriate (inside a Producer or
preferably an XSP page). Read the Javadocs for Java - it pays dividends!

To include static non-XML files which exist on your own server, it's faster
to just do as A above but replace util:include-uri href= with
util:get-file-contents name=



_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.


Mime
View raw message