Security Advisory Concerning Java Deserialization Vulnerability 

Issue date: 18-11-2015
Affects versions: N/A

 

Issue id: SECURITY-9

 

Severity 

Potentially high

Description

Since last week several public news reports have come out concerning a potential Java deserialization security vulnerability.
While Hippo CMS and the Hippo infrastructure are not directly affected, Hippo wants to advise our customers to review their own implementation and usage of public-facing (web) applications and how they should protect themselves against this potential vulnerability.

The potential Java (and other platforms) deserialization vulnerabilities have been described in detail earlier on during the AppSecCali 2015 conference with more direct and concrete analysis providing example exploits last week through a blog post by Foxglove Security.

In essence this vulnerability concerns the ability to leverage remote executable exploits over (Java) deserialized objects from untrusted sources. When an application supports deserialization of such objects from untrusted sources it might be trivial to pass exploit code through for example a HTTP request.

After a thorough investigation and assessment Hippo has concluded that the Hippo CMS product and the Hippo infrastructure is not vulnerable  to this exploit directly.

One potentially vulnerable usage, which is by default not enabled, is providing access to the Hippo Repository over the RMI protocol.
Such RMI-enabled access is typically only to be used for administrative and 'behind the firewall' operational purposes, never to be used for public anonymous access.
But because it is technically possible to enable RMI access to the Hippo Repository, we strongly advise existing customers to make sure this is only done within a properly secured context, if at all.

It must be noted that the documented Java deserialization vulnerability makes use of known, and possibly so far unknown, 'Gadgets' or exploitable vectors of specific and commonly used 3rd party Java libraries.
In particular the Apache Commons Collections 3.x and 4.x libraries (multiple versions) have been marked out to provide such a 'Gadget' to enable the exploit of the Java deserialization vulnerability.
Such 'Gadgets' themselves must not be misunderstood as providing the vulnerability themselves, as further explained by the recent statement from the Apache Software Foundation itself.
Other, so far unknown, 'Gadgets' in other common Java libraries or even the Java runtime itself might exist exposing similar exploitable vectors.

The Apache Software Foundation already has followed up on these recent publications with a specific Commons Collections fix release 3.2.2 which effectively blocks the exploit through this library.

The current (and earlier) versions of Hippo CMS do use and bundle the above mentioned vulnerable Commons Collections library, but do not expose  the Java deserialization vulnerability.
The above mentioned advisory on not using, or only providing restricted access over RMI however must be followed as providing public facing unauthorized access over RMI must be considered a vulnerability.

Hippo will shortly provide updates to all their current versions and modules using the Commons Collections library with the above mentioned fix release 3.2.2 to ensure this particular exploit is not exposed in the future nor through possible customer specific functionalities built on top of the Hippo CMS product.

For customer-specific functionalities built on top of the Hippo CMS product, we also strongly advise our customers to review and validate their own implementation against Java deserialization usages and access paths, as those might pose a potential security vulnerability.

 

Instructions

We advise our customers to review and validate if they currently might have non-default RMI access to Hippo Repository enabled (note again: by default RMI access is disabled and it should only be enabled on the backend (not public facing) for admin purposes).
How to check if RMI access has been enabled:

• review the Tomcat context.xml file and the web.xml file for the CMS application:
  It should not  have a start-remote-server  context-param element defined with value true, like in the example below:

  <context-param>
    <param-name>start-remote-server</param-name>
    <param-value>true</param-value>
  </context-param>
  

  or (less common) a similar init-param element defined on the RepositoryServlet (cms web.xml only) like this:

  <servlet>
    <servlet-name>Repository</servlet-name>
    <servlet-class>org.hippoecm.repository.RepositoryServlet</servlet-class>
    <init-param>
      <param-name>start-remote-server</param-name>
      <param-value>true</param-value>
    </init-param>
  </servlet>
  

We also advise our current customers to review and validate if they are using and exposing Java deserialization capabilities to possible untrusted sources, and if so take appropriate measurements to protect such access.

Furthermore, while Hippo will provide updates for its current releases to update the usage and dependency for the Commons Collections library to version 3.2.2, existing Hippo CMS projects can already (temporarily) update to this fixed version by adding the following changes in their root Maven project POM:

<properties>
  ...
  <commons-collections.version>3.2.2</commons-collections.version>
  ...
</properties>

<dependencyManagement>
  <dependencies>
    ...
    <dependency>
      <groupId>commons-collections</groupId>
      <artifactId>commons-collections</artifactId>
      <version>${commons-collections.version}</version>
    </dependency>
    ...
  </dependencies>
</dependencyManagement>