Emory University UTS Security Advisory EMORY-2009-01
Topic: Command Execution in Hannon Hill Cascade Server
Original release date: March 19, 2009
Hannon Hill's Cascade Server product is vulnerable to a command
execution vulnerability. An attacker with access to an unprivileged
account within Cascade Server could exploit this vulnerability to run
arbitrary commands on the system with the privileges of the user who
started Cascade Server.
* Cascade Server, all versions
An attacker with access to an unprivileged account within Cascade
Server could exploit this vulnerability to run arbitrary commands on
the system with the privileges of the user who started Cascade Server.
The privileges of that user are necessarily sufficient to gain full
administrative control of Cascade Server - elevate privileges, conduct
denial of service, etc.
Cascade Server allows its users to write XSLT stylesheets which it
uses to transform XML source data into HTML or other formats. Cascade
Server employs the Apache XML Project's Xalan-Java XSLT processor to
perform these transformations.
The Xalan-Java site states, "For those situations where you would like
to augment the functionality of XSLT with calls to a procedural
language, Xalan-Java supports the creation and use of extension
elements and extension functions... Extensions written in Java are
directly supported by Xalan-Java."
Because Cascade Server does not restrict the kind of XSLT code users
are able to enter, any user with access to edit XSLT stylesheets can
cause Cascade Server to execute arbitrary Java code. Using the
java.lang.Runtime class, Java can run shell commands.
While the privilege level of the Cascade Server process may prevent
an attacker from gaining complete control of the host system, that
privilege level is necessarily sufficient to gain full control of
No full solution exists at this time, but see Recommendations, below.
Hannon Hill is working to develop an official solution, and customers may
wish to monitor its progress using the Hannon Hill ticketing system
(requires a customer account).
It may be possible to limit exposure in the following ways:
* Grant the ability to edit XSLT files only to trusted users.
* Enforce strong passwords for accounts with XSLT editing privileges.
Cascade stores user passwords as base64 encoded SHA1 hashes in the
password field of the cxml_user table, and can be audited with any
SHA1-capable password cracker. For example, to extract hashes from a
MySQL database in a form useable by John the Ripper's
(http://www.openwall.com/john/) raw-sha1 format:
echo "select userName, password from cxml_user" \
| mysql cascade \
| perl -i -ne 'use MIME::Base64; /^(.*?)\t(.*)/ && print "$1:" . unpack("H*", decode_base64($2))."\n"'
* Run Cascade Server as a user with as few privileges as possible.
* On UNIX systems, run Cascade Server in a chroot environment.
This exploit example assumes the ability to create and edit blocks,
stylesheets, and pages. It's also possible to exploit the
vulnerability simply by modifying an existing stylesheet.
Create a stylesheet with the following contents: