Java serialization issues have been around for years, but haven’t really garnered much attention until recently, when it became clear that attackers could use vulnerable classes to perform deserialization on untrusted data. Particularly, if the deserialization occurs pre-authentication. Java's type check will ensure you only get valid object trees by strictly validating the expected type. Unfortunately, by the time the type checking completes, compromised code could be executed wreaking havoc on the server.
Name of the Vuln/Sonatype ID: CVE-2018-10237
Type of vulnerability: Deserialization DoS
In the following example, unbounded memory allocation allows remote attackers to conduct Denial of Service (DoS) attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable.
In other words, the server will allocate memory well above what the application needs to run.
The Attack Mechanics:
Guava classes accept a caller-specified size parameter (`n`), this is what attacker will leverage. By tampering with the request and supplying a request for an abnormally large amount of server memory, much more than is needed to deserialize the object, an attacker could force the server to allocate all its memory, initiating a DoS attack.
Let’s look at a real world example.
Consider an API which uses the vulnerable Google Guava library and allows its users to send requests comprising serialized Java objects to the API server over a network. An attacker who is able to access the API endpoints, could easily tamper with a request containing serialized objects and transmit it to the server. This request, when deserialized, would lead to the server allocating large amounts of memory unnecessarily and eventually crashing or becoming unavailable.
Why it matters:
Administering this attack could take down any server running this component with this Guava vulnerability.
The best remediation path:
Set a limit on the size of the object graph that servers will accept. For Java, narrow the classes that can be deserialized from “any class available” to an application, down to a context-appropriate set of classes.
DevOps-native organizations with the ability to continuously deploy software releases have an automation advantage that allows them to stay one step ahead of the hackers. Customers of Sonatype Nexus were notified of CVE-2018-10237 within days of the discovery. Their development teams automatically received instructions on how to remediate the risk.
If you're not a Sonatype customer, and want to find out if you're using the vulnerable version of Guava in a specific application, you can use Sonatype's free Nexus Vulnerability Scanner to quickly find out.