Bug 1291292 (CVE-2015-5254)

Summary:	CVE-2015-5254 JMS ObjectMessage: unsafe deserialization
Product:	[Other] Security Response	Reporter:	Martin Prpič <mprpic>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	abhgupta, aileenc, bbaranow, bmaxwell, carnil, ccoleman, cdewolf, chazlett, csuconic, csutherl, dandread, darran.lofthouse, dedgar, dimitris, dmcphers, dosoudil, gvarsami, jason.greene, java-sig-commits, jawilson, jboss-set, jcoleman, jgoulding, jialiu, joelsmith, jokerman, jshepherd, kconner, ldimaggi, lgao, lmeyer, mmccomas, myarboro, nwallace, pgier, psakar, pslavice, psotirop, rnetuka, rsvoboda, rwagner, soa-p-jira, s, tcunning, tdawson, tiwillia, tkirby, twalsh, vtunka
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
See Also:	https://issues.redhat.com/browse/ENTMQ-1704 https://issues.redhat.com/browse/ENTESB-5536
Whiteboard:
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:	2019-06-08 02:46:30 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1320285, 1291293, 1291294, 1293392, 1326962, 1326963
Bug Blocks:	1291295, 1320039, 1385169

Description Martin Prpič 2015-12-14 14:10:15 UTC

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 14:11:28 UTC

Created activemq tracking bugs for this issue:

Affects: fedora-all [bug 1291293]

Comment 3 Kurt Seifried 2015-12-21 16:26:37 UTC

Upstream has more information on this issue available at:

https://issues.apache.org/jira/browse/AMQ-6013

Comment 5 gil cattaneo 2015-12-21 17:11:17 UTC

(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-25 00:26:36 UTC

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 23:53:24 UTC

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 16:53:07 UTC

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-24 00:53:32 UTC

*** Bug 1320038 has been marked as a duplicate of this bug. ***

Comment 12 Jason Shepherd 2016-04-13 23:39:57 UTC

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 15:02:47 UTC

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 23:28:14 UTC

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 15:35:34 UTC

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