Bug 1291292 - (CVE-2015-5254) CVE-2015-5254 JMS ObjectMessage: unsafe deserialization
CVE-2015-5254 JMS ObjectMessage: unsafe deserialization
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20151208,repor...
: Security
Depends On: 1320285 1291293 1291294 1293392 1326962 1326963
Blocks: 1291295 1320039 1385169
  Show dependency treegraph
 
Reported: 2015-12-14 09:10 EST by Martin Prpič
Modified: 2018-05-10 14:15 EDT (History)
51 users (show)

See Also:
Fixed In Version: ActiveMQ 5.13.0
Doc Type: Bug Fix
Doc Text:
It was found that use of a JMS ObjectMessage does not safely handle user supplied data when deserializing objects. A remote attacker could use this flaw to execute arbitrary code with the permissions of the application using a JMS ObjectMessage.
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Martin Prpič 2015-12-14 09:10:15 EST
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:

http://activemq.apache.org/objectmessage.html

External References:

http://activemq.apache.org/security-advisories.data/CVE-2015-5254-announcement.txt
Comment 2 Martin Prpič 2015-12-14 09:11:28 EST
Created activemq tracking bugs for this issue:

Affects: fedora-all [bug 1291293]
Comment 3 Kurt Seifried 2015-12-21 11:26:37 EST
Upstream has more information on this issue available at:

https://issues.apache.org/jira/browse/AMQ-6013
Comment 5 gil cattaneo 2015-12-21 12:11:17 EST
(In reply to Kurt Seifried from comment #3)
> Upstream has more information on this issue available at:
> 
> https://issues.apache.org/jira/browse/AMQ-6013
Hi
Thanks but is too late, https://bugzilla.redhat.com/show_bug.cgi?id=1291293#c3
Comment 6 Fedora Update System 2015-12-24 19:26:36 EST
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.
Comment 7 Fedora Update System 2015-12-28 18:53:24 EST
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.
Comment 8 errata-xmlrpc 2016-03-22 12:53:07 EDT
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
Comment 10 Jason Shepherd 2016-03-23 20:53:32 EDT
*** Bug 1320038 has been marked as a duplicate of this bug. ***
Comment 12 Jason Shepherd 2016-04-13 19:39:57 EDT
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:

   https://access.redhat.com/solutions/2190911
Comment 16 Clebert Suconic 2016-06-02 11:02:47 EDT
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.
Comment 17 Jason Shepherd 2016-08-29 19:28:14 EDT
Statement:

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.
Comment 22 Andrej Nemec 2018-05-09 11:35:34 EDT
Mitigation:

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:

https://access.redhat.com/solutions/2190911

You could also mitigate this issue using the features of the Java Virtual Machine added in JEP 290:

http://openjdk.java.net/jeps/290

Note You need to log in before you can comment on or make changes to this bug.