Impact mchange-commons-java includes code that mirrors early implementations of JNDI functionality, including support for remote factoryClassLocation values, by which code can be downloaded and invoked within a running application. If an attacker can provoke an application to read a maliciously crafted jaxax.naming.Reference or serialized object, they can provoke the download and execution of malicious code.

Implementations of this functionality within the JDK were disabled by default behind a System property that defaults to false, com.sun.jndi.ldap.object.trustURLCodebase. However, since mchange-commons-java includes an independent implementation of JNDI derefencing, libraries (such as c3p0) that resolve references via that implementation could be provoked to download and execute malicious code even after the JDK was hardened.

Patches Mirroring the JDK patch, mchange-commons-java's JNDI functionality is now gated by configuration parameters that default to restrictive values. Those parameters are documented here.

Workarounds No. Users should upgrade to mchange-commons-java >= 0.4.0. Earlier versions should be avoided on application CLASSPATHs.

References

c3p0, you little rascal — Hans-Martin Münch c3p0 documentation, security note c3p0 documentation, configuring security

c3p0 version < 0.9.5.4 may be exploited by a billion laughs attack when loading XML configuration due to missing protections against recursive entity expansion when loading configuration.

c3p0 0.9.5.2 allows XXE in extractXmlConfigFromInputStream in com/mchange/v2/c3p0/cfg/C3P0ConfigXmlUtils.java during initialization.