Skip to content

Instantly share code, notes, and snippets.

@apetro

apetro/disclosure_and_local_remediation.md

Last active March 22, 2016 14:30
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save apetro/9c5b75fcfcce6eb78983 to your computer and use it in GitHub Desktop.
Save apetro/9c5b75fcfcce6eb78983 to your computer and use it in GitHub Desktop.
Download ZIP
March 2016 uPortal Commons Collections 3.2.1 Vulnerability private notice
Raw
disclosure_and_local_remediation.md

March 2016 uPortal Vulnerability Disclosure: Apache Commons Collections 3.2.1 usage

This document

This is a uPortal project vulnerability disclosure, pursuant to uPortal's Security Incident Response Plan.

Disclosure timeline

This vulnerability is first being privately disclosed to known adopters and then soon after will be publicly disclosed.

  • Private notification: Tuesday March 15th 2016.
  • Public disclosure: Tuesday March 22 2016.

Affected versions and deployments

Local implementations of recent versions of uPortal exposing Java de-serialization endpoints are affected.

Adopters of certain Apereo portlets, even into portals other than uPortal, where those implementations expose Java de-serialization endpoints, are affected.

In abstract, this vulnerability could affect all recent versions uPortal. Roughly, uPortal 3.0 and later, including uPortal 4.2.1.

In abstract, this vulnerability could affect recent versions of at least these portlets and libraries:

It is very likely that other software libraries, including Portlets, are affected.

It is very likely that many locally authored and locally customized Portlets and other Java software modules are affected.

In practice, uPortal developers consulted believe the vulnerability is not exploitable in most or all uPortals-as-locally-implemented, because uPortals are likely not actually exposing a Java object de-serialization endpoint (because, why would you?).

Exploiting the vulnerability hinges on getting the JVM to de-serialize Java objects from arbitrary serialized form. On triage, it does not appear that uPortal itself or the commonly adopted-with-uPortal portlets actually expose an endpoint that would de-serialize Java objects off the wire. With no such endpoint to call, the Adversary does not have an opportunity to exercise this vulnerability.

However. If in your uPortal implementation you locally implemented custom code or third-party portlets or so that do rely upon Java object deserialization, your implementation is likely vulnerable and it is important that you remediate this vulnerability.

Severity

Successfully exercising this vulnerability allows the Adversary to inject arbitrary code.

This vulnerability scores CVSS 10.0, which is to say, very serious.

The Vulnerability

This disclosure is about a specific exploit path involving a bugged version of Apache Commons Collections. Version 3.2.1 is bugged; version 3.2.2 is not.

Many Java products, including uPortal and products commonly adopted with uPortal, have been depending upon Apache Commons Collections 3.2.1 and so are affected by this vulnerability.

This exploit path is only an instance of a larger JVM Java object deserialization security concern. Therefore, patching Commons Collections blocks Commons Collections' participating in the vulnerability, but it does not guarantee that there is no other path to the vulnerability in your uPortal runtime environment.

Patching locally

If your uPortal implementation is active, you are likely already familiar with building and deploying your local customization of uPortal. The first patch option is for you.

If your uPortal implementation is dormant, if somehow you're not comfortable re-building and re-deploying, no worries. It is feasible to patch this issue in situ. The second patch option is for you.

Patching in source

Fundamentally, the fix is to adopt Commons Collections 3.2.2 rather than 3.2.1.

0. Back up first

You're using reasonable source control solutions, right?

Anyway, back up your code before making any change, of course.

1. Patch your pom.xml

Rather than depending upon v3.2.1,

<commons-collections.version>3.2.1</commons-collections.version>

instead depend upon v3.2.2

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

You can see examples of doing this in recent Pull Requests / commits to the affected projects.

Pro tip: You can also constrain the version of Commons Collections drawn in by transitive .jar dependencies, via the technique demonstrated in the fix for the Web Conferencing Portlet.

2. Re-build and re-deploy

Build and deploy your uPortal as you normally do.

Patching in-situ, as deployed

If you are unable or do not prefer to re-build your software from source, you can instead patch this issue in-situ, in your software as deployed.

0. Back up first

Always save a backup of your deployed environment before editing it in place, right?

1. Shut down Tomcat

The Tomcat Servlet container will likely be happier if you make this change cold, with Tomcat down, rather than hot, with Tomcat up.

2. Replace the .jar

For all instances of

commons-collections-3.2.1.jar

instead replace with

commons-collections-3.2.2.jar

in your deployed environment.

You can download the .jar from the Commons Collections download page (and check the checksum against those posted there).

3. Start Tomcat again

Having shut down your servlet container, you'll need to start it again.

Now upgrade all your dependencies

Portlet containers are goofy with multiple classholders, so it probably does some good to upgrade uPortal's direct dependency on Commons Collections. However, to really exorcise vulnerable versions of Commons Collections from your uPortal instance, you also need to patch or upgrade all portlets and other software modules that depend on and are pulling in vulnerable versions of Commons Collections.

Next steps for the uPortal project

The uPortal project and related portlet projects are in process upgrading dependencies to use the fixed Commons Collections .jar and then cutting releases, with the upshot that a uPortal 4.2.2 patch release should ship with no usages of the vulnerable Commons Collections 3.2.1 .jar.

This disclosure facilitates proceeding with that patching and releasing.

How do I tell if this vulnerability has been locally exploited?

That's hard, because it's an arbitrary code injection vulnerability where arbitrary code is injected into a live JVM, that is, in-memory, without necessarily any particular file system or other attack signature.

If you find you were running a Java object deserialization endpoint open to untrusted callers, you may wish to proceed as if your server is compromised. It would be difficult to be confident that the exploit had not been exercised. The only saving grace here is the presumed rarity of running a Java deserialization endpoint listening to untrusted callers.

How do I keep Commons Collections 3.2.1 out of my builds?

For projects building using Maven, consider banning the dependency using the maven-enforcer-plugin.

Learn more

Acknowledgements

reported this issue (and proposed fixes) in various Apereo contexts.

have been working the uPortal project security incident response process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment