Java Object Serialization Vulnerability (CVE-2015-4852)

Submitted on 11. November 2015 - 10:30 by mbu.
Last update on 12. November 2015 - 13:31.

The Issue (CVE-2015-4852)

Java's object serialization feature allows for remote code execution with exploits based on the widely used Java library "commons-collections" or other classes [3]. The core of the problem is the acceptance of unvalidated user input as object data which is then deserialized into objects. Serialized Java objects are used in the Java RMI protocol or custom applications transferring data using object serialization. Depending on application design, serialized Java objects may also be transmitted in HTTP parameters or headers, putting public web applications at risk.

Are Airlock Products Vulnerable?

Airlock WAF, Airlock WAF Add-ons, Airlock Login and Airlock IAM are not affected by the described vulnerability, because Java's object serialization features are not used on externally-provided input data.

How to Protect Your Applications

Completely eliminating the vulnerability in all applications may take some time. However, there are a couple of central protection measures that immediately mitigate the risk of being exploited remotely, such as deploying a virtual patch on Airlock WAF.

Central Protection

1. Deploy Virtual Patches on Airlock WAF

Define a custom Deny Rule on Airlock WAF to protect back-end applications. The filter given below blocks serialized Java objects transferred from web clients to back-ends.

In the Configuration Center, navigate to "Application Firewall/Deny Rules"
Add a Custom Deny Rule Group and a Custom Deny Rule
Add the pattern "\brO0ABX" for parameter values, header values, and paths. (Note: fourth character is the letter 'O', fifth character is a zero).
Enable the new Deny Rule Group and the new rule on all affected mappings (i.e., mappings for Java applications).
Activate the new configuration

2. Use Upstream Authentication

Protect public access to your applications using upstream authentication, e.g., using Airlock Login. Hence, vulnerable applications will no longer be exposed to anonymous users on the Internet.

Application-specific Protection

3. Remove Vulnerable Classes from Classpath

To protect against the exploits in [2], identify the commons-collections jar files on application classpaths and remove the classes

- InvokerTransformer
- InstantiateFactory
- InstantiateTransformer

As jar files are actually zip files, this can be done using any archiving tool supporting zip. Note, however, that other classes may be leveraged for similar attacks [3].

4. Apply Input Validation

Of course, disabling object serialization is the safest way to go. If your application must use object serialization, apply input validation before deserializing objects, e.g., by whitelisting acceptable objects.