JMS Object messages depends on Java Serialization for marshaling/unmashaling of the message payload. There are a couple of places inside the broker where deserialization can occur, like web console or stomp object message transformation. As deserialization of untrusted data can leaed to security flaws as demonstrated in various reports, this leaves the broker vunerable to this attack vector. Additionally, applications that consume ObjectMessage type of messages can be vunerable as they deserlize objects on ObjectMessage.getObject() calls.
This issue was fixed upstream in Apache ActiveMQ 5.13.0. Additionally, when using ObjectMessage message type, you need to explicitly list trusted packages. To see how to do that, please take a look at:
Created activemq tracking bugs for this issue:
Affects: fedora-all [bug 1291293]
Upstream has more information on this issue available at:
(In reply to Kurt Seifried from comment #3)
> Upstream has more information on this issue available at:
Thanks but is too late, https://bugzilla.redhat.com/show_bug.cgi?id=1291293#c3
activemq-5.6.0-14.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
activemq-5.6.0-14.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in the following products:
Red Hat OpenShift Enterprise 2.2
Via RHSA-2016:0489 https://rhn.redhat.com/errata/RHSA-2016-0489.html
*** Bug 1320038 has been marked as a duplicate of this bug. ***
You need to have deployed a JMS publisher, or subscriber which accepts JMS Object Message to be vulnerable to this flaw. Also, in order to connect to a HornetQ JMS server in EAP, a username, and password needs to be provided.
However if you do deploy a JMS publisher, and subscriber, and don't trust the messages sent to you by your clients, you could work around this issue by installing a Java agent which restricts the classes which can be deserialized. This is an article with the recommended approach:
I don't think this is really an issue for Artemis or HornetQ
ObjectMessage is only a tool for the clients to generate and parse their User objects.. they belong to the client, not to the server.
In Artemis everything is a byte Array. The thin JMS layer exists to bring an utility to the client to generate and parse objects. they belong to the client.
We could maybe protect clients by adding restricted packages on the classLoading. But we can't be over restrictive here as that would break a lot of users using ObjectMessage.
Although MDBs run inside the server's VM at Wildfly. But I'm still not convinced this is an issue, since the producer would need access to the queue at producer's clearance.
A malicious message producer needs to authenticate to EAP in order to send messages. Also, the use of JMS ObjectMessage needs to be chosen by the developer of the application. Therefore this issue is rated as moderate.
If you do deploy a JMS publisher, and subscriber, and don't trust the messages sent to you by your clients, you could mitigate this issue by installing a Java agent which restricts the classes which can be deserialized. This is an article with the recommended approach:
You could also mitigate this issue using the features of the Java Virtual Machine added in JEP 290: