[<prev] [next>] [day] [month] [year] [list]
Date: Fri, 23 Sep 2016 12:14:14 +0100
From: Martyn Taylor <mtaylor@...hat.com>
To: security@...che.org, Matthias Kaiser <matthias.kaiser@...e-white.com>,
oss-security@...ts.openwall.com, bugtraq@...urityfocus.com,
dev@...ivemq.apache.org, users@...ivemq.apache.org
Subject: [CVE-2016-4978] Apache ActiveMQ Artemis: Deserialization of untrusted
input vunerability
Severity: Important
Vendor: The Apache Software Foundation
Versions Affected: Apache Artemis 1.0.0, 1.1.0, 1.2.0, 1.3.0
A class implementing the Serializable interface is free to implement
the “readObject(java.io.ObjectInputStream
in)” method however it chooses. This readObject method is used during the
deserialization process, when constructing a java object from a serialized
byte stream. It is possible to implement the method in such a way that can
result in java code being executed during the deserialization of an object
of this class (gadget class).
The JMS specification outlines a getObject() method on the
javax.jms.ObjectMessage
class. The Apache Artemis implementation of this method allows
deserialization of objects, from untrusted input. There are several places
where Apache Artemis uses this getObject() method. In the JMS Core client,
the Artemis broker and the Artemis REST component. These Artemis components
may therefore be vulnerable to a remote code execution attack. Successful
exploitations of this vulnerability rely on these "gadget classes" being
present on the Artemis classpath and the sender of the untrusted input
being authenticated and authorized to send messages to the Artemis broker.
The code execution exploit may happen under the following circumstances:
· In the JMS client when consuming an object message.
· In the REST module when a REST client requests to consume a message that
was originally sent as an object message (cross protocol).
· In the Artemis management layer, when a client sends an object message to
a management address.
· On the broker when an AMQP client consumes a message that was originally
sent as an object message (cross protocol).
For this exploit to occur the sender of the compromised message needs to be
authenticated and authorized in order to send the message to the Artemis
broker and affected classes (gadget classes) present on the Artemis class
path.
Mitigation:
To secure the Apache Artemis broker and management layer:
** Upgrade to 1.4.0.
For the Apache Artemis REST module and Apache Artemis JMS client.
** Upgrade to Apache Artemis 1.4.0
** Configure the appropriate deserialization white/black lists as outlined
in the Artemis documentation.
Credit: This issue was discovered by Matthias Kaiser of Code White (
www.code-white.com)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
