Do the unserialization/deserialization exploits against the commons-collections library affect Red Hat JBoss products? (CVE-2015-7501 )

Solution Verified - Updated -

Environment

  • Red Hat JBoss A-MQ 6.x
  • Red Hat JBoss BPM Suite (BPMS) 6.x
  • Red Hat JBoss BRMS 6.x
  • Red Hat JBoss BRMS 5.x
  • Red Hat JBoss Data Grid (JDG) 6.x
  • Red Hat JBoss Data Virtualization (JDV) 6.x
  • Red Hat JBoss Data Virtualization (JDV) 5.x
  • Red Hat JBoss Enterprise Application Platform 6.x
  • Red Hat JBoss Enterprise Application Platform 5.x
  • Red Hat JBoss Enterprise Application Platform 4.3.x
  • Red Hat JBoss Fuse 6.x
  • Red Hat JBoss Fuse Service Works (FSW) 6.x
  • Red Hat JBoss Operations Network (JBoss ON) 3.x
  • Red Hat JBoss Portal 6.x
  • Red Hat JBoss SOA Platform (SOA-P) 5.x
  • Red Hat JBoss Web Server (JWS) 3.x

Issue

  • An issue was reported for the Java Object Serialization affecting the JMXInvokerServlet interface:
    http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/

  • Could an unauthenticated attacker, able to access the JMXInvokerServlet, execute arbitrary code in the context of the user running the JBoss server?

  • We have received an alert from our security team on zero-day vulnerability. Does Red Hat aware about this vulnerability & workaround on this fix? If yes, please provide details.
  • Is there a remote code execution vulnerability in the commons-collections library?

  • Do CVE-2015-7501 or CVE-2015-4852 affect the JBoss Middleware Suite?

Resolution

If you cannot patch, the quickest way to resolve this specific deserialization vulnerability is to remove the vulnerable class files (InvokerTransformer, InstantiateFactory, and InstantiateTransformer) in all commons-collections jar files. Any manual changes should be tested to avoid unforeseen complications.

If you package commons-collection library in your application you may still be vulnerable, even after the forthcoming patches are applied. You'll need to make changes to the commons-collections library yourself if you package one.

This issue, as it affects the JBoss Middleware Suite, should be referred to as CVE-2015-7501. Other vendors have referred to it as CVE-2015-4852.

Root Cause

This is a multi-part flaw, with several conditions necessary to allow an exploit. For remote-code execution (RCE) from an attacker to work, the configuration must:

  • Accept untrusted serialized data
  • Allow blind deserialization of that data
  • Classes with the vulnerability must be available in the classpath

For more information about the JMXInvokerServlet specifically please see this article

Customers are encouraged to take a "defense-in-depth" approach to securing their systems. Red Hat Product Security is determining the best path forward generally for its products with regard to this vulnerability and the larger class of deserialization vulnerabilities.

More information about the issues of Java deserialization can be found in the Red Hat Security Blog. We'll also have more blogs on this topic in the near future.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

25 Comments

Hi ,

We are using jboss-eap-6.2. on executing grep -Rl InvokerTransformer from our JBoss home, we found this jar file on the result modules/system/layers/base/org/apache/commons/collections/main/commons-collections-3.2.1-redhat-2.jar along with commons-collections-3.1.jar on application deployment.
Are we vulnerable to this attack? Is there any security patch available to resolve if we are vulnerable?

If you are using jboss-eap-6.2 you are vulnerable. There will be a patch released for the latest version of eap-6. In addition to applying that patch, it's advised to patch the version you have in your application deployment.
If you cannot wait for a patch, please remove the vulnerable classes from those jars yourself and test before redeploying.

Hi Jason,

Is the patch available or is still pending?

Thanks.

I am not finding patch in download , Please can I get the link for patch download .

Hi Babul - at this time we're working on the patch, it is not available. As Jason pointed out before, there is a mitigation listed above to remove the vulnerable classes if you can not wait for the patch. Once the patch is available, this document will be updated, errata notifications will be published, along with other customer communications.

Hi,
Is it enough to desactivate the JMXInovker on EAP 6.4 ?
What about BPM Suite ?
Regards

Hi Guillaume,
EAP 6.4 doesn't come with the JMXInvokerServlet, that's only deployed in earlier versions of EAP. If you need a workaround for the issue please remove the 3 class files from commons-collections.jar using a tool like 'zip' on linux:

zip -d commons-collections-3.2.1.redhat-3.jar org/apache/commons/collections/functors/InvokerTransformer.class

If you do that, make sure to test the updated commons-collections jar(s) before deploying to production servers.

A patch for EAP 6.4 is actively being worked on, and will be available as soon as it's passed our quality assurance process.

Hi,
regarding the execution of arbitrary code: what kind of code? Java code or any binary of the system Jboss is running on? Couldn't the use of the Java Security Manager (policy file) prevent some of the code execution (e.g. the execution of binaries)?
Regards

Java code directly, however unless there are security manager or OS (e.g. selinux) restrictions that Java code could then launch binaries.

As stated in https://commons.apache.org/proper/commons-collections/release_3_2_2.html the problem should be solved in their new release. When will it be part of EAP?

Hello Team, We are using EAP 6.4.0 version. are we vulnerable to this attack or JMXInvokerServlet ?
In addition to this, we have copied the commons-collections-3.2.2.jar to the /opt/jboss/jbosslatest/modules/system/layers/base/org/apache/commons/collections/main/ location and removed the commons-collections-3.2.1.redhat-3.jar

Are we secure then sufficiently ?

Thanks
Jivendra

EAP 6.4.0 doesn't contain the JMXInvokerServlet, see https://access.redhat.com/comment/989743 Red Hat haven't tested the latest upstream version of commons-collections 3.2.2, use it at your own risk.

Thanks for your reply.

We have a multi-tenancy hosting platform with the below versions of JBoss installed. jboss-eap-5.0.1 jboss-eap-4.3.0.GA_CP08 jboss-eap-5.1.0 jboss-eap-5.1.2 jboss-eap-6.2.0 jboss-eap-6.3.0 jboss-eap-5.2.0 jboss-eap-6.4.0

Can you provide an ETA for a patch release for each where possible. ?

For a list of currently patched products, see the 'resolve' tab on this page. You can download patches for the binary distributions from the download section of the customer portal

Is it safe to replace commons-collections-3.2.1.redhat-3.jar with the 3.2.2 version instead of using the proposed solution (removing the classes) ?

+1 Same question for me

we are using eap 6.3.0. is this efected?and how can I found path.

thanks.

Hello. Yes, EAP 6.3.0 is impacted by this issue. Please follow the guidance in the Resolve Tab of https://access.redhat.com/security/vulnerabilities/2059393 .

Apply 6.3 Update 03, and then the patch for 6.3.3.

Hi There,

We are using jboss-eap-6.4 and still got the same problem issue. We would like to know how to solve it. Could you please to provide the solution to us?

Thanks!

If you are on the latest update of 6.4, you should not see this issue. It has been resolved since the release of 6.4 Update 05. The latest update can be found on the 6.4 patches/updates download page. Hope that helps.

Our current using version is Red Hat JBoss Enterprise Application Platform - Version 6.4.14.GA

In that case, you are running with the fix. If you are saying that you are still vulnerable, then perhaps something is wrong with your installation? You should contact support for specifics to verify you have properly applied the update. You can create a new case and provide the details on what your observation is along with product details and log files.

Would be nice if you specify the version like 6.4.21, which I have had a hard time to find ;-)

Mahesh,

I understand how frustrating it can be when you can't easily identify a specific version that a fix may have landed in. This is something that I find can be very difficult to communicate when dealing with multiple products based on a core implementation such as the application server components used in Red Hat JBoss Enterprise Application Platform (JBoss EAP) and the other JBoss components.

The Apache commons-collections: Remote code execution during deserialisation (CVE 2015-7501) page referenced in the solution provides the list of affected versions and their corresponding patches (if available). In the case of JBoss EAP it indicates that 6.4 versions up to 6.4.4 were impacted and a hotfix was made available for 6.4.4. Beginning with 6.4.5 the fix for the vulnerability was included as indicated in the Red Hat JBoss Enterprise Application Platform 6.4 Update 05 Detailed Description page.

We try to keep the specific details in one place and for security vulnerabilities, this information is provided in the CVE vulnerability or advisory notice maintained by the Red Hat Product Security Team. This ensures that the communication is properly propagated to subscribers and the information is as up-to-date and accurate as possible.

Hopefully this information helps but I know it does not address the original problem with not being able to locate the specific information.